[stefan_]

Except they all already use the insanity that is SELinux because they found users and groups too limiting for their "guaranteed to break production at runtime" security scheme. People suggesting we need user accounts for isolation are a generation behind the engineers tasked with papering over security issues.

[ratorx]

SELinux is definitely over-engineered, but it’s not for the same problem as file permissions. File permissions are purely for files, whereas increasingly Linux does not nicely follow the philosophy of everything being a file. Once you have non-file resources and capabilities, it is very tempting to attempt to generalise permissions beyond them and if you attempt to bolt it on, you’ll get something like SELinux.

I wouldn’t say file permissions are necessarily outdated. You can get pretty far using something like systemd capabilities, which are much more supplementary to the existing Unix file permission model.

The very best approach to this IMO is OpenBSD pledge and unveil. Managing the permissions as part of the binary itself is much less fragile, although it doesn’t have exactly the same threat model. It also has the added benefit of temporal safety, which I’m not sure you can do with SELinux.

[candiddevmike]

AppArmor tends to break less because it doesn't resolve around esoteric file metadata for labeling, IME. Keep the policy definitions separate.

[cwillu]

Who is “they?” SELinux is not universal.