27 ms·

> 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 sh

by 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 ago
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.
- nextos 2y ago
  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.
  - 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 ago
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).
- nextos 2y ago
  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.
sirspamalot108 2y ago
[flagged]

by nextos 2y ago

ratorx 2y ago

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.

nextos 2y ago
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.
- 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 ago

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).

nextos 2y ago
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.

sirspamalot108 2y ago

[flagged]