State of Linux Desktop Security

https://bjornpagen.com/blog/linux-security

by zeva • 6 years ago

69 85 6 years ago

bjornpagen.com

throwaway888abc• 6 years ago

There is also Qubes for security sensitive work

https://www.qubes-os.org/ https://www.whonix.org/

Still, I like the point/aim author is taking.

mirimir4• 6 years ago

Right. Or where it matters less, VirtualBox or KVM.

And where it matters more, hardware compartmentalization.

infokiller10• 6 years ago

And where it matters more, hardware compartmentalization.

With the caveat that you need to use secure air-gapped communication, and you probably want to use Qubes on each of the separate machines as well [1].

[1] https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...

blaser-waffle5• 6 years ago

Is Qubes worthwhile if I'm doing anything more complicated than web browsing and lite scripting? (bash/perl, maybe some light python or flavor of js)

henriquez• 6 years ago

I wish the author had linked to some citations on a lot of the points brought up. It came off as flippant, particularly the dismissal of snap (of which I am not a fan but not aware of gaping security holes other than the forced updates). But possibly this piece wasn’t intended to blow up on HN.

Some of the stuff like code signing is philosophically incompatible with a modular OS where people are often compiling their own binaries, but many of the points raised are good.

AnthonyMouse4• 6 years ago

Windows and MacOS enforce signature checking on all binaries.

This is not a meaningful security feature. If the signature has to be from the manufacturer then you can't so much as write your own shell script, which is useless. That is a cage, not a security measure. But if the user can sign their own binaries then the signature is the equivalent of the execute bit -- you have to tell the system something is executable before it will execute it. Linux has had that forever.

bitbang• 6 years ago

I'd rather shit Legos than have to deal with binary signature checking.

craftinator• 6 years ago

On Linux, just automate it.

imtringued• 6 years ago

The signature could be tied to a sandbox. Signed apps each have their own sandbox. User signed apps all get thrown into the same sandbox. Otherwise I agree. A signature can't actually meaningfully exist as a security feature in an open source operating system where you are able to compile every piece of software yourself.

AnthonyMouse4• 6 years ago

Signatures and sandboxing are independent. You can have either one without the other.

noobermin2• 6 years ago

You're going to make ipsec heads explode comparing signing a binary to setting a file's execute bit.

infokiller10• 6 years ago

Signatures are meaningful when the keys are more secure than the servers hosting the data.

If you download software from a hacked server that serves you malware, the signature check will fail. In contrast, the execute bit can be changed by anyone.

The problem is that you need to get the authentic public key of the software distributor to verify the signature. If an attacker is able to forge the public key, they can easily forge the signature and the signature check will succeed.

AnthonyMouse4• 6 years ago

The problem is that you need to get the authentic public key of the software distributor to verify the signature.

Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.

Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.

pcwalton• 6 years ago

Firefox uses seccomp-bpf too. https://searchfox.org/mozilla-central/source/security/sandbo...

alcoholic_byte2• 6 years ago

Well. The principle of Linux was and still is to give tools and have users use them. It gets out of the users way to use them. One can always use firejail or other sandboxing solutions to do that. Chrome itself is a security nightmare, always with the mic on and listening. Microsoft and Apple also have CVEs unattended. Binary checks before starting a program? Why I have a package-manager that does the checks. Untrusted binaries are ususally installed with local user rights in a seperate path or best, not run at all(never needed to turn to some website offering tools since moving to linux aeons ago). Not all distros use Flatpack or Snap, and I hope it remains that way regardless of how fiercely Canonical is pushing for it. Granted, the out of the box security provided by Linux as a Desktop OS is behind the Windows/MacOS one;Only think of the non-existing firewall rules on a fresh Ubuntu installation. But I think that is ok, because installing Linux is a conscious decision, unlike using a preinstalled Windows or MacOS. So, if you do that move from one OS over to another, the user should read up and not expect the community to hold their hands without asking questions.

Not everything is perfect, yes moving the toolchain would be nice, but then again, most a community run projects, so the user needs to know about locking their basement as well. Hence the audience is/should be more technical minded anyways.

IMHO another post about comparing apples and oranges leaving out second-level effects. Just an example: Looking for CVE-entries https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=MacOS , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Linux , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Windows . We see that MacOS has the fewest and Windows the most CVEs. (So it doesn't matter that Microsoft closes the CVEs quickly and Debian might take some time (haven't really run metrics on that one), there is a huge attack-surface on Windows, compared to Linux and new once have to pop up all the time :D) That isn't looking into severity, because a chaining of medium CVEs might also lead to a compromise as well ,and not everything requires system or root. User might be fine as well. I see a reflection of favoured OS. Only few people use MacOS (some artists, companies streamlining their assets for maintenance and rent,etc.). Windows, on the other hand, was always the big dog on the desktop market. Naturally, maleware authors focus on the biggest market.

cwyers• 6 years ago

The principle of Linux was and still is to give tools and have users use them.

A circular saw is a tool, one without a handguard is a bad tool even if it cuts wood well.

twothamendment• 6 years ago

I found that a 14" circular saw with the guard removed was a great tool. It demanded a lot of respect - much like some tools in Linux.

./run-saw --yes-without-the-guard

j88439h843• 6 years ago

Extremely well said.

nonick• 6 years ago

Chrome itself is a security nightmare, always with the mic on and listening

I can understand the mic being always on as a privacy nightmare, but how is this a security nightmare?

atq2119• 6 years ago

Lack of privacy is lack of security. This is true even if you're only interested in "hard" security concerns. For example, consider that keystrokes can be reconstructed from audio, which means that being able to record from your mic means being able to gather your passwords.

alcoholic_byte2• 6 years ago

As the other guys said. And it is not just that. Chrome is, considering it's architecture and purpose, a minion in a botnet, working for google to harvest data. They even got a lawsuit pending because they were even tracking users in privacy mode. This stuff cannot happen with IE, or FF. Brave, Vivaldi, I dunno, don't use them, but I am weary that they are using the same rendering-engine (and soon Redmond as well) (well depends where the G-men(what a pun) put their mischiveous code in). Because it is a pipedream to expect a privacy-compatible product from a company that build it's empire on mining the users data to the bit.

pjmlp4• 6 years ago

Which is why 98% of the desktop and mobile users don't care about Linux.

That is the price to pay when only technical minded users are the target group.

izacus• 6 years ago

And that's ok, there's nothing wrong with tools being specialised for certain small markets. It makes them significantly better for those people than being forced to use a ill fitting tool for someone else.

Consolidation and lack of competition makes for a worse experience.

tsimionescu2• 6 years ago

While I think you are right to some extent, articles like the parent's are mostly aimed at people claiming 'Linux Desktop is actually better for grandma'. The reality is that grandma is going to be better protected while running Windows or MacOS or Chrome OS. If she's running Linux, she is wide open.

Also, some of the most common practices on Linux that are claimed to be superior from a security standpoint are just bad. For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse, despite what many people think. A common recommendation in advanced projects is to add their apt/yum repo to your system, which is not only equivalent to downloading stuff off the internet, it is also you registering them as trusted to deliver updates to your system forever. On Windows, you at least have some anti-virus tool scanning for known malware, so you still have a small chance that you won't be allowed to run some well known malware from years ago.

lifty2• 6 years ago

The external provided software repos are one thing I find superior on Linux, compared to macOS and Windows. It gives you an OS managed way to do updates to 3rd party providers, as opposed to each app shipping their own update code, many times running as a background daemon. On macOS, the situation for apps outside of the app store is a ghetto. Not sure about Windows as I don’t use it often, but I suspect it’s similar to macOS.

blaser-waffle5• 6 years ago

The reality is that grandma is going to be better protected while running Windows or MacOS or Chrome OS. If she's running Linux, she is wide open.

Strongly disagree. The linux desktop has something like 1% of the marketshare and is far from the lowest hanging fruit. And basic, sane security defaults are plenty good for simple web browsing and emailing.

My grandma used to get calls 2-3 times a month from "Microsoft" and "Comcast" trying to get her to download team viewer and cough up some passwords to Windows 8. She eventually got phished by downloading something dumb via email. I put her on the Ubuntus, with some tweaks, and she's doing fine. 10/10 would do it again.

For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse

Grandma ain't installing Steam or an obscure 3rd party metasploit framework -- standard Ubanto repos are fine. She doesn't need rpmfusion to access Office365 emails.

On Windows, you at least have some anti-virus tool scanning for known malware

Clam-AV is a thing in Linux and works fine -- we used it on mail relays a while back and had decent results. If you're putting trust in the default MS virus protection you're naive.

29athrowaway• 6 years ago

What about SELinux or AppArmor?

gizmo686• 6 years ago

I made a post about that here [0].

I don't think anyone is seriously applying those to a desktop system.

They are both based on the Linux Security Module subsystem; which is just too low level to be effective at desktop security. Essentially, they suffer from the same problem as traditional UNIX permissions: no one cares that the attacker cannot access system files. The user's bank account is in their home directory.

[0] https://news.ycombinator.com/item?id=23155269

RMPR4• 6 years ago

At least they won't be able to install drivers[0]

0: https://xkcd.com/1200/

nwmcsween2• 6 years ago

Seccomp is painful, you need to fork a 'seccomp' fork as you cannot seccomp the parent and child to differing permissions, With pledge this is simple.

viraptor2• 6 years ago

Forking then setting a policy in parent works though (if you don't need to spawn more workers). Or you can have a "worker spawner" process.

nwmcsween2• 6 years ago

And that defeats a large portion of how programs work by first having root to bind to low ports, etc then forking a worker not to mention you have to restructure your program for seccomp vs ifdef for pledge. There are a bunch of ways of sandboxing on Linux but not many projects use it because implementing it is just painful, compared to pledge even external projects outside of openbsd will accept simple ifdef patches to support easy sandboxing.

saagarjha• 6 years ago

glibc's allocator is primitive compared to LLVM's Scudo allocator, which mitigates use-after-frees and heap overflows.

Ok, who actually uses Scudo (I've certainly never heard of it)?

strstr• 6 years ago

I believe it’s considered to be somewhat hard to integrate with, but worth it if you can. It was/is Fuchsia’s default allocator.

tkubacki• 6 years ago

"flatpak and snap are both security nightmares" and then link to flatpak article... Come on at least bother to explain... As far as I know - with all bad publicity snap has recently - it does isolate package and you don't give root to package maintainer.

Bold claims no arguments

zenhack• 6 years ago

I'm dubious of some of these -- the code signing thing strikes me as not that compelling for reasons other comments have already pointed out. Others are very valid.

But more than "how are we doing vs Apple and Microsoft?" I'd kinda prefer to set the bar a bit higher. Desktop operating systems (all of them, at least with actual users) are just completely architecturally backwards for the reality of our modern security landscape, and what users need from their system. Protection boundaries are still mostly between different users. for most systems that's borderline useless, as there's only one user. Meanwhile every app runs with the full authority of the user and can do anything they can do.

Smartphones are a little better; Android equates "user" with "app" which is at least vaguely useful. But the permissions you end up with are still too coarse grained.

There are better designs out there. For example: web pages can ask the user for a file without getting access to everything the user owns (or at least in the case of Android, all of their files). Why can't native apps do this?

pjmlp4• 6 years ago

They do in UWP, macOS, ChromeOS sandboxes, to different levels of detail, but so far most developers have resisted to them thus users can't get to use them.

infokiller10• 6 years ago

I agree that Android app security model is much better than desktop Linux (of course, they had the privilege of designing a new system without backward compatibility concerns and after learning lessons from other systems).

The main issue with using that model for desktop Linux is that apps where not developed with this model in mine. So when an app wants to access your webcam, it tries to do it directly and doesn't ask the OS to grant permission. Similarly when accessing any files.

I guess it's possible in theory to trace any system calls the app makes and accordingly trigger permission requests to the user. Since that didn't happen, maybe it just breaks to many apps to be effective.

BTW, installed apps could create their own UID to isolate themselves, but most developers/distros don't bother doing it. I should not that I did see a significant improvement in running systemd services as separate users, but I rarely see it for user facing apps.

A better option than only using a separate UID is containerization, and things like docker, firejail, bubblewrap, etc, are useful here.

But Linux containers are not considered secure enough (at least compared to VMs). The real gold standard in terms of security is QubesOS, but you pay for that security in performance and ease of use.

j88439h843• 6 years ago

What about firejail?

blaser-waffle5• 6 years ago

elaborate -- what is this tool and why should i consider it?

j88439h843• 6 years ago

Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.

https://firejail.wordpress.com/

woodruffw• 6 years ago

I think the author is generally right (especially about sandboxing!), but picked a few funny examples:

* Windows page signing is a feature of Authenticode, and applies specifically to "high integrity" kernel drivers. It's basically a niche of normal code signing and should be treated as such.

* Windows just (as in, within the last 6 months) got hardware-backed control flow protection, via Intel CET. They had to add a new debug type (`IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS`) to the debug section to make space for it in the PE format. It'll probably take a few years to become popular, assuming that Microsoft hasn't badly broken it the way they did RFG.

* Modern iOS/Apple mobile hardware is generally a poor contrast: it's homogenous in terms of CPU features in ways that Linux can only dream of, and benefits from Apple's walled garden approach. Linux distros can barely get people to fetch automatic updates; getting them to buy CPUs with hardware CFI features (a la Apple's PAC) is a pipe dream.

pjmlp4• 6 years ago

On Android side of the mobile OS fence, Google is now enforcing ARM memory mitigations starting with Android 11 and it builds up on the OS lockdown features that they have been adding since Android 7.

DyslexicAtheist• 6 years ago

it starts all with application devs and distribution package maintainers. users shouldn't even have to know about these things.

- things could be improved if (userland)application maintainers (NOT packaging maintainers) actually bothered to ship apparmor (and/or SElinux) profiles and also properly maintain them for all packages. This will only happen if distributions make them mandatory instead of relying on some 3rd party maintainers.

- it seems that QA in general (and test coverage especially) within Linux distributions isn't very strict (I'm only familiar with Debian/Ubuntu here).

- Haven't seen many services make use of the systemd.exec[1] restrictions in unit files. should be mandatory for all system services to implement these (has to be done by devs not distribution packaging maintainers).

- While it's nice that Debian claims that apparmor is enabled by default now it hides an ugly truth that becomes visible when running `ps auxZ | grep '^unconfined'` ... most applications don't even have a profile and even when you install apparmor-profiles-extra there are only a handful.[2]

- firejail is cool but most people never even heard of it (there is also an overlap in some functionality between apparmor/firejail - and even systemd.exec)

There is always going to be a trade-off between strictness/QA and integrating changes/new packages. but raising the bar can only be possible by having developers maintain these things better and holding them accountable during the distribution packaging. We can't expect the user to figure out what system-calls a process makes so that they can whitelist it themselves.

If Linux on the desktop is ever to compete from a security pov with Apple/Windows then this needs to be done under the hood. While many of my family (including my 70 yro auntie) uses Linux successfully they should never have to know what apparmor/SElinux/etc even is.

[1] https://www.freedesktop.org/software/systemd/man/systemd.exe...

[2] The Debian wiki (https://wiki.debian.org/AppArmor/HowToUse#Enabling_profiles) states: "Beware though: many profiles are not up-to-date and will break functionality in enforce mode, be ready to debug!" <- this shifts the effort to the user (in other words security is available only if one is prepared to implement it by themselves).

user234683• 6 years ago

More broadly, even in systems such as Windows, arbitrary programs have way too much access to the system, especially the filesystem. A lot of effort is put into patching exploits that allow for a program to gain root, yet this is largely irrelevant for desktop users [1]. If malware takes over system files, the operating system can just be reinstalled. The relevant threat is malware encrypting or stealing personal files (which every program can access), such as pictures, documents, browsing history, etc. Currently, all it takes is a single sketchy freeware utility without admin access to destroy/steal all of your personal data.

I would envision a whitelist system where programs by default can only access files in their own directories, but the file explorer would mediate access to files opened in the program. So if a file is double clicked in explorer, the corresponding program gains access to that file. Likewise, the "Open" feature in the program would have to call the explorer API for the file selection dialog, which would also give it permission. There are certainly lots of edge-cases that would have to be ironed-out.

Another nobrainer is to put permission for network access on a whitelist, in addition to other permissions. It could work similarly to the permissions found on mobile, but it should be possible to install the program anyway without granting it permissions, so that developers don't simply ask for everything as is standard on mobile. Of course, this system would introduce UX headaches for non-technical people which would need to be worked on, but it should at least be an option for security-conscious people.

[1] https://xkcd.com/1200/

doteka• 6 years ago

I’m not sure you’re aware but you basically described the way it works in the latest macOS. If an app wants to touch something in user folders, it has to ask for permission.

sargun• 6 years ago

I'm curious as to what people (dis)like about seccomp?

teekert• 6 years ago

How are confined snaps on wayland unsafe? Why talk about X when it is clearly phasing out?

dTal2• 6 years ago

Perhaps what is broken is not our operating systems, but the notion that a computer program running on one's own computer can be an untrusted agent of a third party. I don't the tools in my collection to be isolated from each other, dangerous creatures in a computerized zoo. I want them to be composable elements of a cohesive whole. I want them to share data so promiscuously that is difficult to tell where one program stops and another begins. Today, this vision of computing is best realized in the free software world, and I don't believe that is a coincidence. To make it work, your tools must be trustable, and the problem of trustable computing is fundamentally intertwined with the issue of free software. Can it be reconciled with a commercial model of software? I don't know, but if it's a choice, then I've made mine.

sam_lowry_• 6 years ago

I will take this into my fortune file!

dTal2• 6 years ago

I'm flattered! In that case do fix my typo: "I don't want the tools".

infokiller10• 6 years ago

While I can appreciate your vision, that seems too detached from the current reality.

Software development is a highly distributed system with many human participants with different (and sometimes conflicting) goals and skills. And to make it effective, you almost always need to reuse software created by many other people that you don't know (which incidentally creates a huge opportunity for supply chain attacks).

In this reality, you get very little assurance about the authenticity and security of anything you use.

RMPR4• 6 years ago

Any app running under Xorg can see the contents of any other app runing under Xorg.

It's one of the problems addressed by Wayland

JonAtkinson• 6 years ago

Wayland remains very immature, and it still has significant shortcomings in hardware support. It's a beta-level technology at best, while Xorg has 20 years of stability behind it. It isn't responsible to suggest it as an alternative.

RMPR4• 6 years ago

Wayland remains very immature

Many people (me included) use Wayland as a daily driver, so I guess it's mature enough to be used, and I don't even use a DE with all the convenience, I use Sway, coming from i3, and everything I used is working fine, either with an alternative, or relying on XWayland.

it still has significant shortcomings in hardware support

Apart from Nvidia (which is not that great with Xorg either) I don't know what you're referring to.

It isn't responsible to suggest it as an alternative

Some mainstream distributions (e.g. Fedora) have defaulted to Wayland, are you calling the maintainers irresponsible?

sprash6• 6 years ago

Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks.

The fact that nobody really uses them should tell you that the sandboxing craze and whitelisting is mostly if not completely security theater and hostile to the general workflow typical for Desktop applications.

Wayland addresses none of those problems. Wayland is merely just a protocol that can be used to blit some bitmaps together. The protocol says nothing about security except that those problems should be dealt with other protocols which are not part of Wayland.

infokiller10• 6 years ago

Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks.

One notable exception is OpenSSH, which uses the SECURITY extension with the -X flag (which is their recommended way to use X11 forwarding).

RMPR4• 6 years ago

Any app running under Xorg can see the contents of any other app runing under Xorg.

This is one of the problems addressed by Wayland.

sprash6• 6 years ago

People rarely run untrusted software on FOSS systems. If you can't trust your package manager and your distrobution you have all kinds of problems the least of which is sandboxing applications.

The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account.

The notion that every application must be 100% sandboxed is mostly security theater and will make your life with daily work in the real non-theater world a living nightmare.

kanox• 6 years ago

The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account.

Do you also run a separate display server? I'm not convinced a truly malicious executable can be stopped by boundaries between users.

sprash6• 6 years ago

Yes, I run those programs in a separate Xorg session. If I need it on the same session I simply spin up a Xephyr window.

tinus_hn2• 6 years ago

Many people just paste command lines they find on the internet which start with

    curl ... | bash

sprash6• 6 years ago

And what do you want to do about it? Do you want to sandbox Bash? That would make Bash completely useless.

infokiller10• 6 years ago

If you define untrusted software as anything not coming from your distro's official package manager, many people run lots of untrusted software on their Linux systems. Think of PPAs (Debian/Ubuntu/etc), the AUR (Arch/Manjaro), and many other package managers (pip, conda, npm, cargo, etc.).

sprash6• 6 years ago

You have always the option to put programs that you don't trust into a jail. It just shouldn't be mandatory.

Besides, the only good way to solve that problem is namespaces as they are used in Plan9. Sadly Unix/Linux took the wrong turn at some point (probably with the introduction of sockets).

blaser-waffle5• 6 years ago

Lookin at you rpmfusion...

blackrock• 6 years ago

Is there any hope that Linux will ever become a microkernel?

arminiusreturns2• 6 years ago

Linux distros are behind on implementing modern binary exploit mitigations.

Compile from source, use only trusted package managers, and sandbox and compartmentalize when possible.

Linux distros have no concept of sandboxing

They may be inadequate or need improving, but these concepts are there, if rarely used by default.

Any app running under Xorg can see the contents of any other app runing under Xorg.

There are ways to prevent this without saying "Wayland".

The only good sandoxing API provided by the Linux kernel is seccomp-bpf, and the only program that uses it is Google Chrome/Chromium.

The very link to the wikipedia entry for seccomp shows otherwise...

Also a friendly reminder that Debian is always behind on CVEs, and I'm sure that most distros don't fare any better.

This is a good point, and one of the reasons I think that the future will belong to rolling release style distros with a faster CVE cycle.

Just the few things that stood out to me, not a piece by piece analysis.

noobermin2• 6 years ago

What mitigations exists for the Xorg apps?

arminiusreturns2• 6 years ago

Qubes, running rootless helps but doesnt stop it, xephyr with selinux sandboxes, nothing that completely fixes the issue.

State of Linux Desktop Security

Related Stories