News for hackers. Stuff that matters.
Re:SELinux is unmanageable; just turn it off if it gets in y... by goodpoint on Wednesday April 27, 2022 @06:34AM (#31178301)
> Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?)

100% test coverage does not guarantee absence of vulnerabilities in any way.

> you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee.

Having sandboxed many things, this is plain false.

Normal applications and daemons have no reason to call reboot() or stime() and so on in any obscure code path.

If they do, the sandbox should stop them and that's a feature and not a bug.

Re:SELinux is unmanageable; just turn it off if it gets in y... by staticassertion on Wednesday April 27, 2022 @08:52AM (#31179235)
Their point about test coverage is that you don't know what syscalls will be made, or with what arguments, without running the program with enough coverage to find out.

This is probably the most well known issue with sandboxing - maintaining the sandbox. It's especially hard with seccomp, because you could upgrade your distro, or a dependency, and suddenly you're making a different system call.