6 ms·

These days, systemd is better/easier to sandbox _services_ than SELinux. SELinux/AppArmor is still the best way to protect individual GUI and user apps (anythi

These days, systemd is better/easier to sandbox _services_ than SELinux. SELinux/AppArmor is still the best way to protect individual GUI and user apps (anything not ran from systemd basically).

mbakke 5y ago
I don't have much experience with SELinux, but at least in my org the base policy is to run anything started interactively by the user (or root) in unconfined_t, i.e. with protections disabled. That is, the same command that gets denied by SELinux through systemd will run fine (and unprotected) when started from a shell. Do you write your own policies for individual end-user programs?
p_l 5y ago
Easier, maybe. Better, nope. The breadth and detail available just don't compare, and not in the way where systemd can even touch the scope available to SElinux
- candiddevmike 5y ago
  Can you expand on that? In my opinion, systemd has far more controls for process security over SELinux (networking, cgroups, nspawn sandboxing, etc).
  - p_l 5y ago
    Out of those, the only things that aren't covered by SELinux are things that would be expected to be set by wrapper/launcher process (modifying namespaces - which covers nspawn and setting cgroups). Everything else, i.e. actual run-time access decisions, is more fine grained and controllable through SELinux, including level of access control like whether a program can listen on a socket or bind a socket, while still permitting it to connect.
- mst 5y ago
  SElinux is more capable in theory but so much less usable/discoverable in practice that I suspect anybody who isn't truly dedicated to doing SElinux right will end up averaging better security via the systemd route. (and I say this based on both observation and personal experience, I have some stuff to harden later this year and I'm really hoping I'll be able to involve somebody who -has- that level of SElinux knowledge but plan B is almost certainly going to be 'mst does his best with the unit configs')
  - p_l 5y ago
    That's why I won't even try to suggest SELinux is easier. It's definitely easier to apply some sandboxing through systemd, but it's pretty coarse grained and mostly seems to hit some relatively easy wins involving capabilities dropping and stuff that is often hidden deep inside PAM. Good start, but I wouldn't call it "better" ultimately.
  - PeterWhittaker 5y ago
    As someone who does a fair amount of SELinux professionally, I’d mostly agree with this: getting started can be daunting, so one could likely get far more value from a short time focusing on systemd security. But if one can spare the time, SELinux can secure everything, not just systemd services. It all depends on the threat vectors one faces.
kaba0 5y ago
Why not use both? They are not complementary.
- candiddevmike 5y ago
  Why would you use SELinux along with systemd? Systemd can do filesystem permissions declaratively vs SELinux having to label the files individually, e.g.: [Service] ProtectSystem=strict ReadWritePaths=/some/path ReadOnlyPaths=/some/otherpath InaccessiblePaths=/etc
  - PeterWhittaker 5y ago
    One can write extraordinarily short FC files using regexp to apply specific SELinux labels as desired, and control access to those labels with only a few rules. Unlike systemd, they then apply to everything.

These days, systemd is better/easier to sandbox _services_ than SELinux. SELinux/AppArmor is still the best way to protect individual GUI and user apps (anything not ran from systemd basically).

mbakke 5y ago

I don't have much experience with SELinux, but at least in my org the base policy is to run anything started interactively by the user (or root) in unconfined_t, i.e. with protections disabled. That is, the same command that gets denied by SELinux through systemd will run fine (and unprotected) when started from a shell. Do you write your own policies for individual end-user programs?

p_l 5y ago

Easier, maybe. Better, nope. The breadth and detail available just don't compare, and not in the way where systemd can even touch the scope available to SElinux

candiddevmike 5y ago
Can you expand on that? In my opinion, systemd has far more controls for process security over SELinux (networking, cgroups, nspawn sandboxing, etc).
- p_l 5y ago
  Out of those, the only things that aren't covered by SELinux are things that would be expected to be set by wrapper/launcher process (modifying namespaces - which covers nspawn and setting cgroups). Everything else, i.e. actual run-time access decisions, is more fine grained and controllable through SELinux, including level of access control like whether a program can listen on a socket or bind a socket, while still permitting it to connect.
mst 5y ago
SElinux is more capable in theory but so much less usable/discoverable in practice that I suspect anybody who isn't truly dedicated to doing SElinux right will end up averaging better security via the systemd route. (and I say this based on both observation and personal experience, I have some stuff to harden later this year and I'm really hoping I'll be able to involve somebody who -has- that level of SElinux knowledge but plan B is almost certainly going to be 'mst does his best with the unit configs')
- p_l 5y ago
  That's why I won't even try to suggest SELinux is easier. It's definitely easier to apply some sandboxing through systemd, but it's pretty coarse grained and mostly seems to hit some relatively easy wins involving capabilities dropping and stuff that is often hidden deep inside PAM. Good start, but I wouldn't call it "better" ultimately.
- PeterWhittaker 5y ago
  As someone who does a fair amount of SELinux professionally, I’d mostly agree with this: getting started can be daunting, so one could likely get far more value from a short time focusing on systemd security. But if one can spare the time, SELinux can secure everything, not just systemd services. It all depends on the threat vectors one faces.

kaba0 5y ago

Why not use both? They are not complementary.

candiddevmike 5y ago
Why would you use SELinux along with systemd? Systemd can do filesystem permissions declaratively vs SELinux having to label the files individually, e.g.: [Service] ProtectSystem=strict ReadWritePaths=/some/path ReadOnlyPaths=/some/otherpath InaccessiblePaths=/etc
- PeterWhittaker 5y ago
  One can write extraordinarily short FC files using regexp to apply specific SELinux labels as desired, and control access to those labels with only a few rules. Unlike systemd, they then apply to everything.