Mounting home "noexec" and confining ~/.local with SELinux?

Ask Fedora
, , , , ,
1

“The year of the Linux desktop” should come every day, but we are not really prepared.

SELinux confined users are still not really usable to my knowledge.

My question is: can we add small opt-in hardening using this technology?

Idea: nonexecutable home?

I would like to protect my system from malware, which means: you need privileges to install software.

At first glance this sounds like that: lock down /home with noexec, all software needs to be in the system, installed with root permissions.

Impacts

But this is problematic. We don’t want to increase the need to use root, do we?

On an atomic desktop this would mean

Works

  • RPMs
  • systemwide flatpaks
  • binaries, scripts in /usr/local/bin aka. /var/usrlocal/bin
  • QEMU system session VMs
  • rootful podman containers

Does not work

  • per user flatpaks
  • Appimages used with random updaters placing them in ~/Apps or so
  • local scripts in ~/.local/bin
  • cargo, pip, pipx, npm, go,… local development or installed binaries
  • QEMU user session VMs that don’t need root (also in virt-manager Flatpak and GNOME Boxes?)
  • podman containers, toolbx, distrobox

This seems bad…

Alternatives: very different

I would like to throw this in

https://wiki.gentoo.org/wiki/Simple_sandbox

It uses core Linux user process isolation, like Android, by isolating every process in it’s own UUID. There is no need for user namespaces, flatpaks etc. and apps are isolated using standardized and very basic methods, way more secure than Flatpak.

Wayland is reported to work, but I don’t know about portals, pipewire, d-bus and a lot more standards. It feels like fighting windmills while on Android this is standard, just like full SELinux confinement.

Workarounds with less change

The Linux desktop seems to go in this vague direction of user namespaces, containers and isolation through that.

So would it make sense to mount $HOME/.local separately and executable, and only allow a few binaries to execute it’s contents?

This could then restrict exec permissions to flatpak, qemu, podman and we could call it a day. Some development things would be broken, so UX of working in VMs should be improved instead of opening up systems.

These are just my thoughts. Is something like that possible?

Also note secureblue’s approach to only allow user namespace creation to a few allowlisted binaries that run SELinux confined. This is likely very different though.

2

The stability does not differ: Both can cause issues to users. I have done testing on KDE, and back then, noexec broke a lot in the GUI. This was some time ago, and maybe the issues have been resolved since then. However, keep in mind that there are many users who do things that rely on exec in /home. And atm, this is nothing that receives widespread testing, which leads to more stability issues as there are not the same stability guarantees. So this is just like the SELinux confinement something that we cannot set by default, as it would cause trouble to many users, and many would not be able to manage it or to find out how to resovle the issues.

That said, if it works out in your system configuration and with how you use your system, it indeed mitigates some potential security issues. But keep in mind that this makes only sense if any user account has no write access on any partition that is mounted with exec, and vice versa, make everything normal users can write on to noexec.

This means, off the cuff: you have to at least also set /var to noexec to make this useful. As far as it concens me, that is on the to do list, but I would not suggest to just enable this by default or so, and for many users, it remains not realistic to use.

This is not everything that might need exec, not even by default. A problem remains that developers of much software, including GUI, often presume that exec is possible. This means that even if one version works out, it is not clear if a subsequent version still does.

Unfortunately, we still lack a useful means that achieves sufficient isolation of processes, especially on the GUI, while still not ending up in denials of services for a noteworthy amount of users. I currently do not assume that SELinux confinement will reach that level.

My hope for the future is some combination of containerization with a mandatory access control. But in both cases, the question starts with which one is best suited to evolve to that. However, depending on how things evolve, noexec indeed could be part of a final solution.

1 Like
3

Platform monopoly… Google offers money and it worked.

I mean we see what happens if there is no stable platform that devs can program for. Stuff like Electron, or selfmade filepickers that need full system read/write access.

Btw the “sandbox all the things” goal did not make it into the new KDE goals. Nice!

So I suppose this is something freedesktop needs to address, to have it standardized everywhere. Until then, everyone doing their own doesn’t work.