4 ms·

Actually, I have been wondering if using a Linux system as multi-user could be a boon in security. As single user, each and every process has full and complete

Actually, I have been wondering if using a Linux system as multi-user could be a boon in security. As single user, each and every process has full and complete control of $HOME. Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. Without going full QubeOS, get some amount of application separation so my photo utility does not have permissions to read ~.ssh. Create a user account for each application (Firefox, Email, PDFReader, etc). Run each of those applications as the foreign user account. Each application now has its own $HOME with minimal user data. Barring a root-escalation or user-separation bug, the data in your true HOME should be isolated. Even process/environment variable space should be segregated. This also has a win in that it becomes possible to better segregate the threat model of less trusted applications. Doing granular network permissions per application is a bit hairy in Linux, but it is trivial to fully deny network access to a specific user account. Not true isolation, but for the semi-trusted development environment, gets you a little something.

weitendorf 2y ago
For shared local usage or "pet" (as opposed to cattle) servers I'd agree, and in fact this is close to what Linux was designed for, since I'd consider the multiplexing lab server to also be a semi-trusted environment. I'm referring more to how Linux is used in vast pools of "cattle" servers in Cloud, locally by eg one main user (who doesn't need multi-user but probably still needs some notion of "admin" and per-program permissions), or in a corporate setting (where the actual identity system is managed remotely). This is probably >99% of Linux environments.
bombcar 2y ago
Qubes takes that to an extreme: https://www.qubes-os.org/intro/ https://www.qubes-os.org/intro/ and runs every application in a virtual machine.
- rendaw 2y ago
  I was experimenting with taking that to a median using containers in nixos. IMO the distinguishing feature of qubes is the fact that there's chrome indicating the security level of a window based on its vm - I put together https://github.com/andrewbaxter/filterway https://github.com/andrewbaxter/filterway to use with window manager rules to hopefully get the same result.
  - alt187 2y ago
    Interesting! I use Guix, I wonder if the fundamental idea can be translated here too. Do you have any links for the Nix-related stuff?
    - rendaw 2y ago
      Arrg, I just realized I lost my demo system in a recent drive failure. So I don't have anything I can show directly... but this is my recollection. I used systemd-nspawn containers https://nixos.wiki/wiki/NixOS_Containers https://nixos.wiki/wiki/NixOS_Containers . For each container I'd run a `filterway` process with a unique app id outside the container and mount the filterway wayland socket inside the container, then wayland programs in the container would just work IIRC (maybe needed to set an environment variable for the wayland socket, or xdg_runtime_dir or something). I think the wayland compositor itself was running as a user, so I had some setuid commands so that the system bar launch icons could start/stop the containers as the wayland user. IIRC wayland was pretty flexible, just mounting sockets in various places and making sure permissions were set on the socket worked great. Some other quick notes: App ids are optional in the wayland spec, but as long as you don't run any such apps in privileged contexts (outside of a container) you can still visually distinguish those. Also IIRC Sway didn't have the ability to vary chrome based on app id - I thought I'd try to indicate the permission level in the task/system bar instead but I think other compositors do have more powerful window decoration rules.
      - alt187 2y ago
        Impressive! I'm not sure Guix has something similar to nspawn containers Hyprland has a way to put unique borders per appid too, I think.
jolmg 2y ago
That's already what's typical with services, e.g. postgresql.service specifies User=postgres.
godelski 2y ago
> Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. You’ll be interested to learn about systemd-nspawn. You can sandbox stuff with it really easily. It is like chroot so not really resource intensive, lighter than a container. I think a pretty useful thing you can do is boot ephemeral instances. So whatever someone does there gets undone. Useful if you’re doing system testing or CI. Because you just set up the machine once and then your scripts and whatever can do what you want. Perfect example is when trying to test install scripts. Though this is also kinda the point of flatpak and snap. Though these are controversial in the Linux community. Then again a lot it people dislike systemd, though fewer than originally. https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn
- RulerOf 2y ago
  I read a good chunk of that wiki link, but didn't really come away with an understanding of how it differs from just using Docker for sandboxing an app. Did you have any insight there you might share?
  - guappa 2y ago
    It's basically the same as docker but it doesn't use proprietary cloud stuff such as dockerhub. Also occupies like 100kb instead of 40mb because it's C and not go.
  - xorcist 2y ago
    It differs by not being insane. Trivial functionality that actually works. It's what's good about systemd. It doesn't require forwarding sockets or giving free access to root just for building images. It doesn't explode just because you touch your nftables rules. It doesn't suddenly expose a process to the Internet because of some undocumented option. You can use all the normal tools such as auditd and SELinux without having your configuration overwritten by a madman.
    - e145bc455f1 2y ago
SoftTalker 2y ago
> As single user, each and every process has full and complete control of $HOME. I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. This is what OpenBSD's unveil does. Firefox for example only has access to ~/Downloads (and some stuff in ~/.mozilla, ~/.config, ~/.cache) in my home directory.
- 3eb7988a1663 2y ago
  Now this looks promising for mere mortals. I found jart's Linux port of pledge[0] which makes it seem possible to simply wrap utilities through a preceding script. If I couple this with distrobox/podman (which should work fine?) I might be able to pretty seamlessly lock down utilities by default with minimal shenanigans. Assuming it does what it says on the tin, and it can work with GUI apps, this would get me almost all the way. [0] https://justine.lol/pledge/ https://justine.lol/pledge/
Propelloni 2y ago
You can get halfway there with Flatpak and Distrobox. Or you could take a look at some of the "immutable" distros, such as openSUSE Aeon [1]. [1] https://aeondesktop.github.io/ https://aeondesktop.github.io/
- 3eb7988a1663 2y ago
  Those solutions seem more aimed at keeping the system clean vs isolating what resources a program can access. Flatpak does indeed get me part of the way there with better isolation, but available apps seem so scatter shot that I need a fallback mechanism for when there is not an official Flatpak artifact. Distrobox makes a point of indicating they are not a security boundary.
guappa 2y ago
If only firejail existed to do exactly that… it could come packaged in most distributions with sensible profiles that are easy to enable. It might even have a github project that people might reach, something like this https://github.com/netblue30/firejail https://github.com/netblue30/firejail
amelius 2y ago
Yeah that's possible but its still security as an afterthought, bolted onto an existing system. And it's a bad UX also. As a user, I don't want to deal with fake users, for example.
- 3eb7988a1663 2y ago
  *Nix was designed to be multi-user. It's probably the only security boundary that was present from nearly the start. I think there are some rough edges on the user-per-application model, but it should all be scriptable so that the machinations are mostly hidden.
maccard 2y ago
Have you used containers?

weitendorf 2y ago

For shared local usage or "pet" (as opposed to cattle) servers I'd agree, and in fact this is close to what Linux was designed for, since I'd consider the multiplexing lab server to also be a semi-trusted environment. I'm referring more to how Linux is used in vast pools of "cattle" servers in Cloud, locally by eg one main user (who doesn't need multi-user but probably still needs some notion of "admin" and per-program permissions), or in a corporate setting (where the actual identity system is managed remotely). This is probably >99% of Linux environments.

bombcar 2y ago

Qubes takes that to an extreme: https://www.qubes-os.org/intro/ https://www.qubes-os.org/intro/ and runs every application in a virtual machine.

rendaw 2y ago
I was experimenting with taking that to a median using containers in nixos. IMO the distinguishing feature of qubes is the fact that there's chrome indicating the security level of a window based on its vm - I put together https://github.com/andrewbaxter/filterway https://github.com/andrewbaxter/filterway to use with window manager rules to hopefully get the same result.
- alt187 2y ago
  Interesting! I use Guix, I wonder if the fundamental idea can be translated here too. Do you have any links for the Nix-related stuff?
  - rendaw 2y ago
    Arrg, I just realized I lost my demo system in a recent drive failure. So I don't have anything I can show directly... but this is my recollection. I used systemd-nspawn containers https://nixos.wiki/wiki/NixOS_Containers https://nixos.wiki/wiki/NixOS_Containers . For each container I'd run a `filterway` process with a unique app id outside the container and mount the filterway wayland socket inside the container, then wayland programs in the container would just work IIRC (maybe needed to set an environment variable for the wayland socket, or xdg_runtime_dir or something). I think the wayland compositor itself was running as a user, so I had some setuid commands so that the system bar launch icons could start/stop the containers as the wayland user. IIRC wayland was pretty flexible, just mounting sockets in various places and making sure permissions were set on the socket worked great. Some other quick notes: App ids are optional in the wayland spec, but as long as you don't run any such apps in privileged contexts (outside of a container) you can still visually distinguish those. Also IIRC Sway didn't have the ability to vary chrome based on app id - I thought I'd try to indicate the permission level in the task/system bar instead but I think other compositors do have more powerful window decoration rules.
    - alt187 2y ago
      Impressive! I'm not sure Guix has something similar to nspawn containers Hyprland has a way to put unique borders per appid too, I think.

jolmg 2y ago

That's already what's typical with services, e.g. postgresql.service specifies User=postgres.

godelski 2y ago

> Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. You’ll be interested to learn about systemd-nspawn. You can sandbox stuff with it really easily. It is like chroot so not really resource intensive, lighter than a container. I think a pretty useful thing you can do is boot ephemeral instances. So whatever someone does there gets undone. Useful if you’re doing system testing or CI. Because you just set up the machine once and then your scripts and whatever can do what you want. Perfect example is when trying to test install scripts. Though this is also kinda the point of flatpak and snap. Though these are controversial in the Linux community. Then again a lot it people dislike systemd, though fewer than originally. https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn

RulerOf 2y ago
I read a good chunk of that wiki link, but didn't really come away with an understanding of how it differs from just using Docker for sandboxing an app. Did you have any insight there you might share?
- guappa 2y ago
  It's basically the same as docker but it doesn't use proprietary cloud stuff such as dockerhub. Also occupies like 100kb instead of 40mb because it's C and not go.
- xorcist 2y ago
  It differs by not being insane. Trivial functionality that actually works. It's what's good about systemd. It doesn't require forwarding sockets or giving free access to root just for building images. It doesn't explode just because you touch your nftables rules. It doesn't suddenly expose a process to the Internet because of some undocumented option. You can use all the normal tools such as auditd and SELinux without having your configuration overwritten by a madman.
  - e145bc455f1 2y ago

SoftTalker 2y ago

> As single user, each and every process has full and complete control of $HOME. I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. This is what OpenBSD's unveil does. Firefox for example only has access to ~/Downloads (and some stuff in ~/.mozilla, ~/.config, ~/.cache) in my home directory.

3eb7988a1663 2y ago
Now this looks promising for mere mortals. I found jart's Linux port of pledge[0] which makes it seem possible to simply wrap utilities through a preceding script. If I couple this with distrobox/podman (which should work fine?) I might be able to pretty seamlessly lock down utilities by default with minimal shenanigans. Assuming it does what it says on the tin, and it can work with GUI apps, this would get me almost all the way. [0] https://justine.lol/pledge/ https://justine.lol/pledge/

Propelloni 2y ago

You can get halfway there with Flatpak and Distrobox. Or you could take a look at some of the "immutable" distros, such as openSUSE Aeon [1]. [1] https://aeondesktop.github.io/ https://aeondesktop.github.io/

3eb7988a1663 2y ago
Those solutions seem more aimed at keeping the system clean vs isolating what resources a program can access. Flatpak does indeed get me part of the way there with better isolation, but available apps seem so scatter shot that I need a fallback mechanism for when there is not an official Flatpak artifact. Distrobox makes a point of indicating they are not a security boundary.

guappa 2y ago

If only firejail existed to do exactly that… it could come packaged in most distributions with sensible profiles that are easy to enable. It might even have a github project that people might reach, something like this https://github.com/netblue30/firejail https://github.com/netblue30/firejail

amelius 2y ago

Yeah that's possible but its still security as an afterthought, bolted onto an existing system. And it's a bad UX also. As a user, I don't want to deal with fake users, for example.

3eb7988a1663 2y ago
*Nix was designed to be multi-user. It's probably the only security boundary that was present from nearly the start. I think there are some rough edges on the user-per-application model, but it should all be scriptable so that the machinations are mostly hidden.

maccard 2y ago

Have you used containers?