5 ms·
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
by ratorx 2y ago
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.
- nextos 2y ago> 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.
- ratorx 2y agoYeah, 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.
- nextos 2y agoFirejail 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.
- NekkoDroid 2y ago> Firejail and bwrap are setuid sandbox frontends. bwrap does not require SUID, it only needs it if user namespaces are disabled for unpriviledged users.
- sirspamalot108 2y ago[flagged]
- deleted 2y ago[deleted]
- XorNot 2y agoLiterally 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).
- nextos 2y agoFirejail 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.
- sirspamalot108 2y ago[flagged]
- sirspamalot101 2y ago[flagged]
- markhahn 2y agosshd was compromised, and it doesn't access private keys. (well, probably the host key.)