3 ms·
I think the point is that applications can sandbox (parts of) themselves in a way that works across distros and doesn’t require a specific system configuration.
by comex 5y ago
I think the point is that applications can sandbox (parts of) themselves in a way that works across distros and doesn’t require a specific system configuration. Think of BSD pledge(), or browser sandboxes. (Browser sandboxes currently use seccomp on Linux. seccomp is good for when you want to disallow almost all syscalls, which browser sandboxes can do due to their highly elaborate design, including routing all file and network access through another process. It’s not so good for when you would like to keep interacting with the kernel directly but just want to limit accessible file paths.)
- 0xbadcafebee 5y agoI guess what I'm wondering is, are there cases where there's no other option except a sandbox? I get that you basically are shipping apps to random computers that aren't secure, so this is sort of a big band-aid for apps that can't tightly control for how their apps are used. But in terms of merging something into the kernel, wouldn't the kernel devs prefer to improve adoption of least-privilege/MAC LSMs?
- catern 5y agoSELinux is pretty inflexible and incompatible with multi-user systems that deploy stuff without privileges - it assumes you can have global policy that applies to everything, which doesn't work well with containers, or browsers, or even just running things out of your home directory. Hence, kernel devs would like to increase adoption of something that's a little better designed - not SELinux.
- totony 5y ago>SELinux is pretty inflexible and incompatible with multi-user systems that deploy stuff without privileges IMO that's not true -- Android has done a pretty good job at it.