
State of Linux Desktop Security - zeva
https://bjornpagen.com/blog/linux-security
======
zenhack
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?

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

------
dTal
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_
I will take this into my fortune file!

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

------
AnthonyMouse
> 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
I'd rather shit Legos than have to deal with binary signature checking.

~~~
craftinator
On Linux, just automate it.

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

------
pcwalton
Firefox uses seccomp-bpf too. [https://searchfox.org/mozilla-
central/source/security/sandbo...](https://searchfox.org/mozilla-
central/source/security/sandbox/linux/Sandbox.cpp#215)

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

------
throwaway888abc
There is also Qubes for security sensitive work

[https://www.qubes-os.org/](https://www.qubes-os.org/)
[https://www.whonix.org/](https://www.whonix.org/)

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

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

And where it matters more, hardware compartmentalization.

~~~
infokiller
> _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...](https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-using-a-
separate-physical-machine)

~~~
mirimir
Right.

The Tinfoil Chat setup uses optocouplers to enforce one-way data
transmission.[0] And one can use inexpensive CD-R and micro SD cards for
single-use data transfer. But transferring anything but plain text is
dangerous.

0) [https://github.com/maqp/tfc](https://github.com/maqp/tfc)

~~~
infokiller
Thanks for mentioning the octocouplers implementation, it looks very
interesting and I'll look it. Other options I'm aware of to avoid USB and
complex drivers/protocols:

\- Scanning QR codes (for example [https://air-gap.it/](https://air-gap.it/))

\- Audio codes (for example
[https://github.com/romanz/amodem](https://github.com/romanz/amodem))

~~~
mirimir
Wow. That is very cool.

Edit: [https://air-gap.it/](https://air-gap.it/) seems down. But
[https://github.com/airgap-it](https://github.com/airgap-it) is up.

I wonder if one could cut up QR codes, and store pieces separately. If that
were done in Gimp or whatever, there could be multiple copies of each piece.

~~~
infokiller
Do you mean sharding them using something like Shamir Secret Sharing,
splitting in order to be able to transfer/store a large blob, or something
else?

~~~
mirimir
I meant actually cutting them with a sharp knife, or scissors. So you could
hide pieces in different places. For stuff like URLs, passphrases, wallet
seeds, etc.

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

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

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

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

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

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

------
alcoholic_byte
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=MacOS) , [https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=Linux](https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=Linux) , [https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=Windows](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
> 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
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

~~~
blaser-waffle
It sounds like a good idea until you lose a least (or most) significant digit

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

~~~
noobermin
What mitigations exists for the Xorg apps?

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

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

------
j88439h84
What about firejail?

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

~~~
j88439h84
> 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/](https://firejail.wordpress.com/)

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

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

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

~~~
viraptor
Fortunately socket activation is gaining support. The whole idea of having a
privileged process just to bind can be skipped. But even without it, I'm not
sure why it matters for seccomp - you bind then you apply the policy. Just
like typically you first bind, then setuid.

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

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

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

------
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/](https://xkcd.com/1200/)

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

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

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

------
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...](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)

[2] The Debian wiki
([https://wiki.debian.org/AppArmor/HowToUse#Enabling_profiles](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).

------
29athrowaway
What about SELinux or AppArmor?

~~~
gizmo686
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](https://news.ycombinator.com/item?id=23155269)

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

0: [https://xkcd.com/1200/](https://xkcd.com/1200/)

