Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Linux Desktop Security

bjornpagen.com

Post reply on HN
Print view View original

21–30 of 89 posts

Re: State of Linux Desktop Security

#21

Post by woodruffw »

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.

Re: State of Linux Desktop Security

#22

Post by nonick »

alcoholic_byte wrote: post #6

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

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

Re: State of Linux Desktop Security

#23

Post by pjmlp »

zenhack wrote: post #18

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…

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.

Re: State of Linux Desktop Security

#24

Post by pjmlp »

alcoholic_byte wrote: post #6

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

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.

Re: State of Linux Desktop Security

#25

Post by DyslexicAtheist »

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

Re: State of Linux Desktop Security

#26

Post by user234683 »

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/

Re: State of Linux Desktop Security

#27

Post by atq2119 »

nonick wrote: post #22
alcoholic_byte wrote: post #6

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

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

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.

Re: State of Linux Desktop Security

#28

Post by nwmcsween »

viraptor wrote: post #13
nwmcsween wrote: post #12

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.

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.

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.

Re: State of Linux Desktop Security

#29

Post by imtringued »

AnthonyMouse wrote: post #4

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

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.

Re: State of Linux Desktop Security

#30

Post by strstr »

saagarjha wrote: post #14

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

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.
Post reply on HN