Hacker News Reader

Comment by nextos | Hacker News Reader

> NixOS and reproducible builds did not detect the xz backdoor

Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already.

This would make it convenient to run every single process with restricted privileges, including no access to ~/, except those directories that are needed by the task. That would prevent e.g. a rogue pip package from stealing SSH keys.

Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

View on HN

> I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

Right, but this is not part of the security model, it's an incidental attribute of the OS that's there for other reasons and easily solved for if the attacker had prioritized it. The only reason why it didn't work is because the attacker didn't bother making it work on NixOS, not because he couldn't have if he'd wanted to.

>Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

It didn't work on NixOS because the build-time hooks that inserted the backdoor only activated itself when it recognized that it was being built for an RPM or Debian package.

Which could have been adjusted, of course.

You don’t even need to run in a container for this. It’s possible to do this entirely in systemd service configuration. The easiest way is just to have separate user for every service and reduce stuff running as root. You can also restrict filesystem access, network access and even syscall access (although some of this may be implemented as a container under the hood).

Unfortunately, this wouldn’t help with the xz vulnerability because the SSH server is the one loading the compromised library in that case (indirectly). Since SSH itself needs to have access to the private keys, it’s not really easy to secure it against vulnerabilities in the library it loads itself.

On the flip side, unless the vulnerability is in one of the important binaries/shared libraries, the amount of damage it can cause it probably quite contained with simply having good user isolation. Nix can make this analysis really simple (because of explicitly specified dependencies), so you can crack down on critical dependencies a lot more easily.

> It’s possible to do this entirely in systemd service configuration

Sure, but I think that leaves out many use cases. What if I want to e.g. start a Python shell that has access to certain directories, and nothing else, including no network access?

Nix provides a good way of doing that for common use cases, as it has decent support for Firejail. But I would like something like Guix containers, which is convenient for any ad hoc use case. This greatly reduces any security threat. It's a poor-man's QubesOS.

Yeah, I guess most existing Linux stuff that is actually configured (so not SELinux etc) is geared at system processes not user ones. Transparently running all user applications in properly isolated containers would be quite neat.

Does Firejail handle dynamic access (eg. I may want an xz invocation to work on my private keys, but not THIS specific one where I’ve given it a completely different file?).

I quite like pledge/unveil for this kind of thing on OpenBSD, although that’s for a different threat model.

Firejail and bwrap are setuid sandbox frontends. You can wrap e.g. a new xz invocation to let it work on your private keys.

But Nix relies on ephemeral shells and flakes, and they don't play so well with each other. The interface is clumsy. Guix, in contrast, has a pretty nice set of CLI switches for these features.

Even normal distros should prioritize some simple graphical UI for this. Running programs with minimal privileges would result in a significant enhancement of security. The kernel features for achieving this are already there.

> Firejail and bwrap are setuid sandbox frontends.

bwrap does not require SUID, it only needs it if user namespaces are disabled for unpriviledged users.

Literally any container runtime can do this for you. No one does it though because it's annoying as hell to upfront figure out what you want, and then be unable to increase that list later.

Like if I were to try and find a not annoying way to do this, it would be to snapshot and overlay mount my filesystem at process launch time, then give a heuristic warning at process termination about what was changed.

But then we're still into basically SELinux territory which because of course there's upfront things we don't want to allow read access to - i.e. SSH keys.

(don't know what the lesson here is other then "for the love of god could we get a standardized secrets filesystem and/or API or something". Looking at you Hashicorp Vault and ~/.vault-token).

Firejail and bwrap can do this in a relatively convenient way, but adding nix shell on top of that is quite clumsy.

In a regular distro, it is tolerable, but a better UI would be great.

sshd was compromised, and it doesn't access private keys. (well, probably the host key.)

> including no access to ~/

This is such a headache with snap and flatpak though.

If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges".

Some examples of sandboxing issues:

* FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts

* FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program

* Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory

* Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first

* "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files

* Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X

In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit.

The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of.

So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?

You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cmake will spit out a multi-megabyte trace file for me to pick through. (I'm convinced cmake is an elaborate conspiracy to waste developer time.)

> let's make it easy for users to break programs out of the sandbox when it suits them?

At least for Flatpak given the things you described this is quite straightforward via bind mounts. Although it did seem a bit goofy having an entire list of per-application bind mounts in my fstab. Maybe things have improved since I last tried going that route?

> "idiomatic" ... doesn't use a file dialog,

That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals for all supported operations at this point. The only excuse (IMHO) is for missing or broken functionality.

It would be like a system tray widget not working and blaming the DE instead of the program that fails to implement the decently old and widely adopted standard.

> Matrix ... you can't share any files with anyone

Which client is this? Anyway the xdg portal should work. Did the dev try it? Programs should never need blanket access to save or open specific user supplied paths as a one off. That's a large part of the point of sandboxing stuff in the first place.

> That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals

We can state what they "should" be doing until we're blue in the face, but if they "aren't" doing that then it doesn't help.

> Which client is this?

The Matrix one is from a long time ago. It could have been Element? Or Riot? Were they the same thing? Don't know. I only used it briefly.

> if they "aren't" doing that then it doesn't help.

True enough. To be clear I don't fault anyone for not using new or known to be broken or little known standards.

However at some point responsibility has to shift to the developers. There are standard ways of doing things. Just as you can't expect an arbitrary project to support your pet API that hardly anyone uses, developers can't expect major distributions or the majority of users to cater to their refusal to conform to widely accepted standards.

I'm not saying you shouldn't use a particular program. Just that I don't think it's reasonable to fault the tooling for certain things.

This looks like a chicken and egg problem to me. You can't sandbox things properly because things don't specify their required privileges properly. Things don't specify their privileges properly because things aren't sandboxed so there's no need to think about that.

As a user, I quite like the iOS approach, of apps "sharing" their ressources with other apps or asking for permission to access this or that collection of ressources. This can probably be improved and adapted to a non-touch model, but I think the concept is nice.

But, of course, apps have to be built for this kind of environment, so I think there will unfortunately be some janky transition period, with the customary competing, incompatible implementations.

I wonder how much it applies to Guix.

Firejail sandboxing works well on these scenarios. You can trivially grant more or less privileges, including the removal of the entire sandbox if you wish.

It actually ships with rulesets for hundreds of programs that tend to be quite polished and work out of the box.

Personally, I dislike flatpak because it doesn't let me control the dependencies of packaged software, and I feel we loose one of the most important advantages of Linux.

> This would make it convenient to run every single process with restricted privileges, including no access to ~/

Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error. Hell, you sometimes can't even copy-paste an image from one application to another via the copy-paste buffer! Meanwhile on macOS and Windows it works perfectly.

This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.

I mean I could also just not use computers, or the internet and that would be perfectly secure as well.

Breaking or making actively annoying expected and useful functionality isn't security (and has a long track record of leading to workarounds which compromise security).

Oh, i know. I was making a joke at Nix's expense, such that i fully expected to be downvoted for said joke, but i also expected some "nah-uh, that's not why;" and then a page of evangelism for NixOS, the one True™ OS.

> This is by design

Hopefully one day people will finally accept that this is bad design and that humans require compromises on security

>You can often only drag 'n drop from ~/Downloads/

Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.

Then I have to ask for printing to always work. Then something else that I haven't even thought of yet. Security is hard because there are so many details that must be right or you compromise useability/usefulness.

Is it? There is such a thung as GUI automation. It's not a very popular exploit vector because it is visible, and because there are simpler non-GUI exploit vectors available. But nothing fundamentally stops an attacker process from pretending it's accessibility software and taking control of the mouse to do a drag-n-drop.

GUI automation is typically locked down heavily and would not be something you would give to random applications.

> pretending it's accessibility software

That should be a privileged status. If you manage to trick the user into installing malicious software followed by granting it elevated privileges then you likely didn't need such a roundabout method in the first place.

I’ll note that macOS doesn’t necessarily always let you do this the first time, it’ll pop a dialogue saying “hey, you’re cool with this app seeing (your files/other apps files), right?” I wonder if such a thing could be implemented in flatpak.

Why? I am just asking for a simple UI, which Guix already has. Mainly for CLI applications. The idea is to be able to launch an ephemeral shell with any combination of packages, filesystem R/W privileges, and network access in a convenient way.

I think launching e.g. a Python shell with some packages that are potentially compromised and letting those read ~/.ssh and whatever else they want is fundamentally insecure. Rogue PyPI packages that steal SSH keys is not a theoretical security breach, it already happened several times [1].

The current security model in Unix is untenable. But I agree well-implemented sandboxing should be frictionless. What you are experiencing is probably a X or Wayland sandboxing glitch. I also dislike Flatpak, for other reasons, but that doesn't make sandboxing a bad abstraction. It's just that we don't happen to like this particular implementation.

[1] https://www.packtpub.com/en-tw/learning/tech-news/python-lib...

An UI would be fine, but having no permission to access ~/ is a terrible default. It causes a lot of breakage and glitchiness because applications are simply not written with that limitation in mind. This is why Flatpaks often crap out. It will cause a huge amount of applications / binaries to crap out if it became the default in NixOS, and lord knows NixOS has enough sharp edges already.

The best solution would be a framework akin to macOS that pops up 'allow application X to access folder Y from now?' in the UI or in the CLI as a terminal prompt whenever an application tries to access a folder. With a special permission for "full home access" and "full disk access".

The maintainer would just change the sandboxing constraints to weaken the software. Just like they did in the first place. You can try to make obfuscation difficult, but it’s always possible.

It's interesting to observe that every process is already restricted to only be able to do computation by default. Then along comes the OS with a plethora of holes in the sandbox to do various things. And then it's strange that we take those holes for granted and apply bandaid patches over them instead of not creating the holes to begin with. Why can't we ask the kernel to create a new extremely limited memory map and run some code until a certain software interrupt fires, then restore the previous context? Why should we have to start with a fully powered-up process and then close off its abilities, instead of starting with no capabilities except the in/out buffers and computation? In this model, there could be a deliberate backdoor in the computation and it still couldn't do anything besides DoS.