Linux desktop applications are relatively unconstrained by default: they can access the user’s home directory, execute any program, and interact with arbitrary network locations. This free access is convenient, but also raises security concerns around misconfigured or misbehaving programs.
There are several existing tools to help with application security.
Since 2005, Linux has had a “secure computing” feature, seccomp, which allows restricting applications’ access to various resources. Firejail is a program that takes advantage of seccomp to sandbox applications, limiting their access to files and interfaces that the user allows. Firejail also provides a large set of configurations for popular applications, allowing these applications the resources they need and denying the resources they don’t need.
bubblewrap works by creating a new, completely empty, mount namespace where the root is on a tmpfs that is invisible from the host, and will be automatically cleaned up when the last process exits.
There has been some prior discussion of application sandboxing in NixOS, so it sounds like people are interested. I’m interested in continuing the conversation, focusing on how we can move toward a more comprehensive solution that enables convenient but safe application usage by default.
For example, would it be realistic to create a version of nixpkgs that wraps all application binaries in a firejail/flatpack/bubblewrap sandbox execution environment? If not, what would be a better path forward?
Another technology that may be relevant is AppArmor. Currently this is used to ‘armor’ ping and a small number of services. Apparently it is used somewhat more broadly in Ubuntu; I hadn’t thought until now to look up their AppArmor profiles, but, doing so, I see that they have profiles for some important targets that NixOS doesn’t seem to be AppArmor-ing, such as Web browsers and some widely-used services.
I have something based on AppArmor similar to systemd confinement. It only works for systemd services though and is sadly not in a state fit for nixpkgs. It’s been on my todo list to clean it up and post it somewhere, but I’m not sure when I’ll get around to it.
There are even plans (or rather ideas) to expand it for other apps, maybe make it system wide.
In general, for all these approaches, nix can give you the closure of any storepath through exportReferencesGraph/closureInfo. So for path based stuff, you can generate profiles from that with an additional whitelist for paths etc. the application needs.
I’ve also written something like this a while ago for packaging proprietary games. What it basically does is setting up mount/user/pid/uts/ipc namespaces and bind-mount all the runtime dependencies at build time (seeing that comment by @Profpatsch reminds me that I should probably replace it by closureInfo), other dependencies from PATH-like variables and extra paths.
The implementation at the moment isn’t as locked down as I’d want it for a more generic implementation (for example it allows access to the X server), but that’s because - as mentioned - it was built for games (examples: 12) after all.
Qubes-esque + usability + Nix (+ EU funding) sounds interesting, even if subscribing to their announcements was a bit annoying with the email account I wanted to use (details are in a [details] block because they’re… rather off-topic).
(In case anyone else wants to subscribe to Spectrum OS's announcements with Gmail on Android, here's what I did.)
Try to subscribe to the announcements mailing list, which requires emailing a message to a specified address; get told that my blank message was rejected because it was HTML rather than plain text (Gmail for Android can’t send non-HTML messages). Open the Gmail website (in Chrome). I’m on Android, so this defaults to a unhelpfully minimal mobile version of the website; trying Chrome’s “Desktop site” option doesn’t help. Open the website’s hamburger menu, which opens a side pane; scroll to the bottom; select the last option in “Mobile | Older version | Desktop”; on the next screen, with Chrome’s “Desktop site” option enabled, select “Take me to latest Gmail”. Note this results in being returned to the same screen; remember that I can get past this screen by clearing cookies. Clear cookies for mail.google.com. Sign back in. Finally I get the real desktop version of the website. Now go through some more cycles of this and remember to push the right buttons at the right times to get the account I want to use. Accept the fiddliness of the full desktop version’s UI on mobile and finally send the required message in plain text and get subscribed.
