
Fixing the Desktop Linux Security Model - adrelanos
https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172
======
_bxg1
All desktop OSes assume virtually all code that's run on them (natively) to be
trusted. This is in contrast to the mobile security model (at least iOS), and
arguably the web, where all apps are assumed to be potentially-hostile. Apple
is trying to back-port macOS to the more modern model but so far the efforts
seem to mostly be clunky and futile. Windows has UWP and Linux has "Snap",
which sandbox individual apps, but they aren't widely used (and of course any
malicious app wouldn't use them).

When installing anything on your desktop system, keep the above in mind. Never
run anything you don't 100% trust.

I do wonder if package managers actually make this problem worse. As another
commenter pointed out, they encourage people to install random packages
liberally. It's an interesting exception to the "Windows is insecure" trope.

~~~
TwoBit
Windows 10 doesn't work the way you claim all desktop OSs do.

~~~
_bxg1
Last I checked (I suppose this was in Windows 7), it's trivial to write a
Windows desktop app that can directly control the mouse and keyboard input
without even requiring admin permissions.

~~~
sebazzz
Yes which is very useful in videoconferencing. We don't want to run Microsoft
Teams or Skype elevated. You won't be able to control elevated applications
though. You're still on the other side of the watertight hatch.

~~~
danieldk
_Yes which is very useful in videoconferencing. We don 't want to run
Microsoft Teams or Skype elevated._

In macOS, applications do not have permission to capture the screen, control
the mouse pointer, use the mic, use the camera, etc. But the user can choose
to elevate the permission (similar to iOS).

~~~
jcelerier
which as an user infuriates me daily

------
badrabbit
Thank you! Linux desktop is far from secure, even with all these suggested
solutions. The lack of popularity by attackers means defenders and coders
alike focus on mitigations based on assumptions or a small amount of
historical data.

From a bad guy's perspective, they just need a foot in the door and move
laterally if possible.

In my opinon, while all these hardening features are great, nothing beats
behavioral detection and prevention. This isn't easy on linux to be honest,
but a way for admins(power users?) To define rules like "a process tree with
firefox as a parent is running unusual commands or processes" , more or less
what is done with sysmon except with perhaps the audit subsystem would be of
tremendous use. Assuming you can't prevent initial access or exploitation,
what can be done to detect attacker activity on Linux Desktop?

~~~
pdonis
_> From a bad guy's perspective, they just need a foot in the door and move
laterally if possible._

How does the bad guy get a foot in the door?

~~~
znpy
> How does the bad guy get a foot in the door?

If you were using Ubuntu Linux in 2007-2008 you will remember the compiz/beryl
craze. Everybody and their dog wanted the latest version of compiz.

Adding random repositories was not a problem if that got you the latest
version of compiz/beryl.

Until a guy, one of the maintainers of a popular repository, tricked
everybody: in the install scripts he added code to change the desktop
background to an image with a text reading: don't add random repositories from
the internet.

Think about all the random repositories and PPAs that people add to their
systems without thinking. That is an example of how you get a foot in the
door.

~~~
pdonis
_> Think about all the random repositories and PPAs that people add to their
systems without thinking._

This doesn't seem like a "desktop Linux security" problem. It seems like a
"some users do dumb things" problem. You can't fix that with an OS. But I can
"fix" it easily by not adding random repositories and PPAs.

~~~
ironmagma
Lots of security issues are fixed not by “fixing” them but by adding
mitigations which include user approval, surfacing otherwise hidden activity,
and other crutches. At the end of the day it is an automated system and must
do things without the human in the loop, so the best you can do is make “the
loop” visible to the user.

~~~
pdonis
_> user approval_

Adding a repository/PPA does require user approval. You can't do sudo without
knowing you're doing it.

 _> surfacing otherwise hidden activity_

Yes, and Linux gives you plenty of tools to do that, like, say, "ps aux" and
"top" (or the many GUI equivalents in various desktop environments).

 _> At the end of the day it is an automated system_

Remember we're talking about _desktops_ here, not servers. Desktops are not
"automated" in any relevant sense for this discussion.

------
PaulDavisThe1st
In summary: make Linux roughly as annoying as Catalina.

e.g. constantly having to allow applications access to files outside the
initial default sandbox.

e.g. constantly having to grant permissions applications that need "unusual"
system capabilities (e.g. raw I/O)

It also seems clear that this concept ultimately heads towards signing
application binaries, like macOS.

Maybe this is a win for some set of Linux users (maybe even most); it's far
from clear that it's appropriate for all.

~~~
zrm
> e.g. constantly having to allow applications access to files outside the
> initial default sandbox.

Any system that has ordinary users trying to do this for ordinary software
will fail.

Things like apparmor can work well because the author or distributor of a
package knows that it shouldn't ever do a particular thing, so if it attempts
to, that is a bug and it should be refused. The user shouldn't even have to be
aware that this is the case because the program shouldn't even _attempt_ to do
the thing the author/distributor asserted it will never do.

> It also seems clear that this concept ultimately heads towards signing
> application binaries, like macOS.

Linux has had that for years already. Packages are signed by the distributor.
Nobody complains about it there because the device owner can authorize
additional parties to sign packages for their machine, as it should be. Have a
look at the install instructions for Signal Desktop for Debian on signal.org
-- "sudo apt-key add" etc.

You can also install binaries outside the package manager, and then the
filesystem executable bit serves a similar purpose -- disabled by default but
the user can override it.

~~~
danieldk
_Things like apparmor can work well because the author or distributor of a
package knows that it shouldn 't ever do a particular thing, so if it attempts
to, that is a bug and it should be refused. The user shouldn't even have to be
aware that this is the case because the program shouldn't even attempt to do
the thing the author/distributor asserted it will never do._

The AppArmor + vendor-provided profiles doesn't work, because it means that
you have to give most applications access to the user's full home directory.
If you e.g. have an office suite and don't permit full home directory access,
users will bail out because they cannot open files in their random folder
structure. If you permit full home access, it could be exploited to exfiltrate
data, write malicious files, etc.

macOS solves this by using a privileged service for Open/Save dialog boxes. If
you ask for an open dialog in a sandboxed application, it is handled by this
privileged service, which makes the file available in the application's
sandbox. It is quite elegant, because it does not require the user to follow
any additional steps (it works as any other file dialog), but restricts an
application to its own sandbox. Flatpak also follows this approach with its
portal mechanism (which is unfortunately not supported by every application
yet).

~~~
zrm
> The AppArmor + vendor-provided profiles doesn't work, because it means that
> you have to give most applications access to the user's full home directory.

It works fine. Its purpose is to solve a different problem than this.

> macOS solves this by using a privileged service for Open/Save dialog boxes.

There are circumstances where this can be useful, and it would be fine to
implement this on Linux for applications where it's appropriate, but it
doesn't work as a universal rule.

For example, suppose I have a music player app, I choose open, I get the
dialog and choose a playlist. The playlist file is just a list of paths to
music files which were never selected in the dialog. The app still needs to
open all the music files. And the same thing for office documents with links
to images, source code project files etc.

And what about background services? If I install an app to make regular
backups of my home directory then it needs access to the whole thing, and not
just once. Likewise anything that does indexing, malware scanning etc.

So it's still really the same thing. You have an app that asserts it never
needs access to files outside the open dialog and then it can be restricted to
just that, but other apps need to do different things. You need somebody to
identify which apps can do without certain capabilities, the average user is
not equipped for that, so it falls to the author or the packager.

------
arminiusreturns
I like that madaidan is thinking deeply about these issues, and I think this
is a great intro to the subject, along with some very interesting comments on
the page. madaidan is also behind obscurix which is a hardened arch variant
[1]. I tend to think the containerization of apps is the lowest hanging fruit
approach, but I also think that there is a larger underlying issue touched
upon which is the monolithic style of the current linux kernel, which is why I
have also hoped HURD would rise some day, and continue to find minix 3 very
interesting.

All that said, I see one glaring omission: hids. One thing I like to emphasis
with people is that especially in an age of APT, if someone sophisticated
enough is targeting you, you will probably suffer a compromise. One of the
most vital parts of a security model therefor is reducing the amount of time
it takes to discover a compromise. This is highly undervalued in modern orgs
imho.

There are a few different ways to do this, and none are perfect but I tend to
prefer a good HIDS like ossec, sometimes custom scripts checking file hashes,
etc. There is one large weakness here though, which is how often I see a hids
deployed but 1) not configured well, and 2) the logs never get
monitored/ingested/alerted on! If you can combine a good hids and actually
monitor the log outputs, you can discover most compromises fairly quickly with
telltale system actions.

Lastyly, this is also why versioned backup is so important. Because you need
to be able to trust old data pre-compromise. The longer you go without knowing
you are comped, the more likely you have data being restored that is comped
also.

[1]
[https://github.com/Obscurix/Obscurix](https://github.com/Obscurix/Obscurix)

------
polotics
I am surprised no one has mentioned Qubes OS yet on this thread. Are they many
Whonix users not also using Qubes?

~~~
madaidan
Qubes is just the hypervisor. The security within the VM still matters. Whonix
supports being run in Qubes.

[https://www.whonix.org/wiki/Qubes](https://www.whonix.org/wiki/Qubes)

------
nextos
Why no mention of firejail or similar tools?

Sandboxing applications is an excellent way to minimize risks. And firejail
comes with a long set of default rules that make it easy to use without any
configuration.

~~~
madaidan
Firejail has far too large attack surface and is suid root which has resulted
in plenty of privilege escalation vulnerabilities.

[https://seclists.org/oss-sec/2017/q1/25](https://seclists.org/oss-
sec/2017/q1/25)

[https://www.cvedetails.com/vulnerability-
list.php?vendor_id=...](https://www.cvedetails.com/vulnerability-
list.php?vendor_id=16191&product_id=0)

Also see this thread
[https://github.com/netblue30/firejail/issues/3046](https://github.com/netblue30/firejail/issues/3046)

Instead, we're going to use bubblewrap which is similar but with minimal
attack surface. See the sandbox-app-launcher section of the post.

------
znpy
Dumb question: why would somebody prefer apparmor over selinux? Why isn't
selinux cited?

From my (basic) understanding of selinux some limitations could be put in
place using selinux (I'm thinking of, for example, preventing Firefox and it's
children from accessing filesystems outside a predefined path, or labelling
files downloaded using Firefox from accessing certain paths if executed --
using labels and policies)

~~~
FooBarWidget
Apparmor is easier to understand, learn and use. Selinux is definitely more
powerful but the learning curve is so deep. It is not just the security model
that is complex. The documentation surrounding it isn’t that good, and avc
logging is not enabled by default (you need to install some package) so when
something goes wrong I always struggle to figure out how to debug it. Finally,
there’s also this library of existing selinux settings provided by the
operating system that you need to integrate with. That one is largely
undocumented, and what little documentation exists is scattered.heck it took
me a week just to find its source code (hint: it is separated in two different
repos, not obvious st all).

In contrast, apparmor made sense and worked the first time I used it.

So yeah, selinux is more powerful, but by being so difficult to use it
encourages people to go ‘hey something is broken, fsck this I’ll disable
selinux’.

~~~
angry_octet
SELinux is just so complicated. I'm sure there are B&E tools out there that
will just search to see where you have misconfigured it and attack there.

With a really minimal system (like an IOT box) you can lock things down very
tight with SELinux, but not practical for a standard desktop to have full
coverage, it just protects some standard components.

------
jchw
This is all great work, undoubtedly. I do wonder if the app sandboxing story
can be improved further, though. For example, I suspect you can further harden
the defense with a gVisor style approach to sandboxing syscalls and filesystem
access, while still using the same kernel mitigations to protect the sandbox
itself (if not more). But, I don’t know for sure.

~~~
saagarjha
There already seems to be seccomp filters in place.

~~~
jchw
gVisor is a step further: it acts a bit like a user mode kernel, which handles
syscalls and carefully passes them to different components that are
individually insulated with seccomp, etc. The idea there is that even a root
escape gets you nowhere because root in the sandbox can never be root in the
host. You’d first need to exploit the “usermode kernel“ then you are an
unprivileged Linux user with a very strict security profile depending on what
component you have exploited. Exploiting the actual kernel would theoretically
be a lot harder because the syscall surface is no longer directly exposed.

------
traverseda
Why not just run android on the desktop? Seems easier than changing all this.

~~~
michaelmrose
Because there is lots of desktop software available for Linux and virtually
none for Android and the user experience of Android as a desktop is crap.

If I had to choose between Android and windows I would most certainly pick
windows.

------
byproxy
Are there distros that have these 'fixes' built in? Alpine Linux?

~~~
boudin
This short post doesn't talk about a lot of things that are happening like
wayland to address X security issues or flatpak for sandoxing. The way it's
written looks more like marketing than anything else... If you want to build
your own hardened apps and kernel, you can look into Gentoo

~~~
madaidan
> like wayland to address X security issues

The post does mention X's security issues. We are discussing switching to
wayland but XFCE doesn't support it yet.

If we don't switch to wayland, I might add X sandboxing via a nested X server
such as Xpra to sandbox-app-launcher. It's already on the TODO list.

> flatpak for sandoxing

Flatpak is not a good sandbox. It fully trusts the applications and the
permissions are far too vague to be meaningful. For example, many applications
come with "filesystem=home" which means read-write access to the entire home
directory so to escape, they just need to write to .bashrc.

We're using sandbox-app-launcher instead.

> The way it's written looks more like marketing than anything else

Sorry for talking about our recent projects then?

------
stiray
I am developing proper application firewall in form of linux kernel module,
but have encountered issues with the linux "kernel protection. What linux is
doing is making half baked solutions, which are preventing real solutions to
be implemented. It is just crazy. Instead of simple way of defining what
application can do (which affects 99.999% of users), they are implementing
protections against highly advanced threats which are affecting other 0.001%
of targets of APT and preventing to protect all others. It is just crazy.

------
swiley
These ideas are mostly for people that want to run prepackaged, closed,
commercial software. Community maintained software with short dependency lists
doesn’t have this problem.

I run Linux on my desktop for a number of reasons and one of them is not
dealing with stuff like this. If I really don’t like something I dump it in a
container (I know it can get out but at some point you either trust the
software or decide it’s unusably malicious, I mostly only do this when I have
to run node.js crap anyway.)

~~~
minitech
> Community maintained software with short dependency lists doesn’t have this
> problem.

That’s just not true. One of the first things mentioned in the post is
vulnerabilities. An image viewer shouldn’t be able to put your SSH keys at
risk no matter how many memory safety issues it has.

Plus there’s all sorts of software that doesn’t have short dependency lists
that I’m sure you’d still like to use. A web browser, for example?

