3 ms·

I don't know about selinux, but systemd can easily do this: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths= https://www.free

I don't know about selinux, but systemd can easily do this: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths= https://www.freedesktop.org/software/systemd/man/systemd.exe...

throwaway2048 8y ago
This has the same problem, you have to define a systemd unit/service/whatever beforehand, the program can not change these parameters, then signal it wishes to be locked down and prevented from changing them again. That's the real beauty of how the OpenBSD approach works, it lets you incrementally ratchet up the restrictions as various stages of the startup/run loop of a program progress, so you don't have to specify everything a program might ever try to do ahead of time, and have that huge pool of permissions persist throughout the entire life of the program.
- justinsaccount 8y ago
  Between templated unit files and systemd-run things can be a bit more dynamic, but yeah, not at runtime. As I understand it, seccomp can do what unveil and pledge can do, just with a much more complicated API. I wonder if anyone is working on a pledge/unveil compatible wrapper API for seccomp...
  - brynet 8y ago
    Not at all, for example you can't implement the ratchet down semantics of pledge() using seccomp. For instance having initial broader promise set "stdio rpath recvfd", and then irrevocably dropping to a runtime promise of "stdio" after init. This is a very paradigmatic use of pledge(2), which a large portion of the 85% of OpenBSD's base system pledged will demonstrate. unveil(2) would be very challenging, if not impossible. Both would require proper Linux integration and kernel implementation.
    - deleted 8y ago
      [deleted]
  - brynet 8y ago
    People have certainly attempted to cobble something together using different pieces on Linux, but the semantics will never be truly perfect unless a native implementation is attempted.

throwaway2048 8y ago

This has the same problem, you have to define a systemd unit/service/whatever beforehand, the program can not change these parameters, then signal it wishes to be locked down and prevented from changing them again. That's the real beauty of how the OpenBSD approach works, it lets you incrementally ratchet up the restrictions as various stages of the startup/run loop of a program progress, so you don't have to specify everything a program might ever try to do ahead of time, and have that huge pool of permissions persist throughout the entire life of the program.

justinsaccount 8y ago
Between templated unit files and systemd-run things can be a bit more dynamic, but yeah, not at runtime. As I understand it, seccomp can do what unveil and pledge can do, just with a much more complicated API. I wonder if anyone is working on a pledge/unveil compatible wrapper API for seccomp...
- brynet 8y ago
  Not at all, for example you can't implement the ratchet down semantics of pledge() using seccomp. For instance having initial broader promise set "stdio rpath recvfd", and then irrevocably dropping to a runtime promise of "stdio" after init. This is a very paradigmatic use of pledge(2), which a large portion of the 85% of OpenBSD's base system pledged will demonstrate. unveil(2) would be very challenging, if not impossible. Both would require proper Linux integration and kernel implementation.
  - deleted 8y ago
    [deleted]
- brynet 8y ago
  People have certainly attempted to cobble something together using different pieces on Linux, but the semantics will never be truly perfect unless a native implementation is attempted.