5 ms·

If anyone want to look further into sandboxing applications on Linux, you can also look at AppArmor and the sandboxing features built into systemd. I love this

If anyone want to look further into sandboxing applications on Linux, you can also look at AppArmor and the sandboxing features built into systemd. I love this repository for bases for AppArmor profiles[1], really good work. Never found a repository as good for systemd, but there are a few around. [1] https://github.com/roddhjav/apparmor.d https://github.com/roddhjav/apparmor.d

darby_eight 3y ago
Is there any indication Linux is going to adopt a pledge/unveil api in the near future? It's hard to place faith in systems like app armor that rely on system administrators to implement security guarantees.
- boustrophedon 3y ago
  Linux has seccomp and landlock, which are basically harder-to-use versions of pledge/unveil.
  - PlutoIsAPlanet 3y ago
    Someone has combined those things to port Pledge to Linux. https://github.com/jart/pledge https://github.com/jart/pledge
- DEADMINCE 3y ago
  I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Something like AppArmor can protect against a threat without having to rely on the developer to have done the right thing. Pledge/unveil would not help with the xz issue. AppArmor would.
  - darby_eight 3y ago
    > I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Compared to not using AppArmor, or compared to using AppArmor? The situation I'm concerned about is having an opt-in profile. (NB I don't understand how AppArmor works—linux security profiles are super confusing.)
  - planede 3y ago
    I would say that they are different tools for different purposes. Sure, with pledge/unveil/seccomp you trust the process to do the right thing, it's really about restricting against threats external to the process. But it allows the process to have different privileges at different parts of the program, while external restrictions are not that flexible. I think it makes sense to use both. Use external restrictions to only give capabilities that the process will ever need, and within the process drop capabilities when they are no longer needed.

darby_eight 3y ago

Is there any indication Linux is going to adopt a pledge/unveil api in the near future? It's hard to place faith in systems like app armor that rely on system administrators to implement security guarantees.

boustrophedon 3y ago
Linux has seccomp and landlock, which are basically harder-to-use versions of pledge/unveil.
- PlutoIsAPlanet 3y ago
  Someone has combined those things to port Pledge to Linux. https://github.com/jart/pledge https://github.com/jart/pledge
DEADMINCE 3y ago
I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Something like AppArmor can protect against a threat without having to rely on the developer to have done the right thing. Pledge/unveil would not help with the xz issue. AppArmor would.
- darby_eight 3y ago
  > I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Compared to not using AppArmor, or compared to using AppArmor? The situation I'm concerned about is having an opt-in profile. (NB I don't understand how AppArmor works—linux security profiles are super confusing.)
- planede 3y ago
  I would say that they are different tools for different purposes. Sure, with pledge/unveil/seccomp you trust the process to do the right thing, it's really about restricting against threats external to the process. But it allows the process to have different privileges at different parts of the program, while external restrictions are not that flexible. I think it makes sense to use both. Use external restrictions to only give capabilities that the process will ever need, and within the process drop capabilities when they are no longer needed.