5 ms·

Not meant to be a snarky comment, but a serious question: how does this differ from SELinux?

staticassertion 5y ago
It's vastly simpler, for one thing. SELinux is basically a weird DSL/ programming language for describing system interactions whereas systemd is providing a very basic interface for common restrictions. I would pretty much never ask a human being to write SELinux policies unless that was explicitly part of their job whereas I can pretty much point any developer to what systemd is providing and they'll be able to work with it.
tyingq 5y ago
It seems to be using mostly the linux capabilities: https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html So the overlap choice seems to be more around SELinux versus Capabilities. Where SELinux is more fine-grained and tunable, but more complicated also.
- aseipp 5y ago
  It's not just Linux capabilities; on their own Linux capabilities actually suck majorly and are very limited (AKA "crapabilities"). But systemd also makes extensive usage of cgroups and namespacing facilities to back it up e.g. preventing runaway memory/CPU quotas and stopping applications from accessing paths they shouldn't, restricting network access, stuff like that. Some of this overlaps with SELinux (e.g. restricting file access) but the mechanism is fairly different. The overlap/comparison between capabilities, systemds features, and selinux features isn't really well defined in any meaningful way IMO. It's really like 5 different features being used in various ways.
  - PeterWhittaker 5y ago
    I’m curious what you mean by SELinux features not being well-defined? While poorly documented, they are extraordinarily precisely defined, allowing fine-grained control of pretty much everything, all enforced by the kernel with no workarounds, at least in enforcing mode.
chasil 5y ago
SELinux is designed as "mandatory access control," meaning that it is not normally disabled. The normal filesystem permissions of read/write/execute for user/group/other are among those known as "discretionary access controls," meaning that they can be relaxed. The systemd unit security options are discretionary, at the control of the administrator.
- t0astbread 5y ago
  Is SELinux not also in the administrator's control?
  - chasil 5y ago
    An administrator can disable it complete with "setenforce 0" and restore it with "setenforce 1" if necessary. The rules can also be adjusted, and there are a number of tunable parameters. The intent is that it is never disabled.
candiddevmike 5y ago
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')
cpuguy83 5y ago
They are completely different things, and where available should be used together. SELinux is a policy system where policy is enforced via labels. Labels are applied to processes which classify what the process is. Labels are applied to files which define the what classification of process can access the file. The application of labels happens automatically based on policy. Such policy would include the location of the file or the label of the parent process. As an example, the default policy for httpd would prevent httpd from accessing /etc/passwd even though the process is running as (or can be) the root user. I believe you could also do interesting things like prevent httpd from opening a socket on a non-standard port if you wanted to. SELinux is very powerful but complicated. Ideally you use this with distro packages which should have policies already configured for you. Critically it is not one vs the other. Use both if you have it.

It's vastly simpler, for one thing. SELinux is basically a weird DSL/ programming language for describing system interactions whereas systemd is providing a very basic interface for common restrictions. I would pretty much never ask a human being to write SELinux policies unless that was explicitly part of their job whereas I can pretty much point any developer to what systemd is providing and they'll be able to work with it.

tyingq 5y ago

It seems to be using mostly the linux capabilities: https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html So the overlap choice seems to be more around SELinux versus Capabilities. Where SELinux is more fine-grained and tunable, but more complicated also.

aseipp 5y ago
It's not just Linux capabilities; on their own Linux capabilities actually suck majorly and are very limited (AKA "crapabilities"). But systemd also makes extensive usage of cgroups and namespacing facilities to back it up e.g. preventing runaway memory/CPU quotas and stopping applications from accessing paths they shouldn't, restricting network access, stuff like that. Some of this overlaps with SELinux (e.g. restricting file access) but the mechanism is fairly different. The overlap/comparison between capabilities, systemds features, and selinux features isn't really well defined in any meaningful way IMO. It's really like 5 different features being used in various ways.
- PeterWhittaker 5y ago
  I’m curious what you mean by SELinux features not being well-defined? While poorly documented, they are extraordinarily precisely defined, allowing fine-grained control of pretty much everything, all enforced by the kernel with no workarounds, at least in enforcing mode.

chasil 5y ago

SELinux is designed as "mandatory access control," meaning that it is not normally disabled. The normal filesystem permissions of read/write/execute for user/group/other are among those known as "discretionary access controls," meaning that they can be relaxed. The systemd unit security options are discretionary, at the control of the administrator.

t0astbread 5y ago
Is SELinux not also in the administrator's control?
- chasil 5y ago
  An administrator can disable it complete with "setenforce 0" and restore it with "setenforce 1" if necessary. The rules can also be adjusted, and there are a number of tunable parameters. The intent is that it is never disabled.

candiddevmike 5y ago

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

cpuguy83 5y ago

They are completely different things, and where available should be used together. SELinux is a policy system where policy is enforced via labels. Labels are applied to processes which classify what the process is. Labels are applied to files which define the what classification of process can access the file. The application of labels happens automatically based on policy. Such policy would include the location of the file or the label of the parent process. As an example, the default policy for httpd would prevent httpd from accessing /etc/passwd even though the process is running as (or can be) the root user. I believe you could also do interesting things like prevent httpd from opening a socket on a non-standard port if you wanted to. SELinux is very powerful but complicated. Ideally you use this with distro packages which should have policies already configured for you. Critically it is not one vs the other. Use both if you have it.