Lennart Poettering writes:
See the discussion around seccomp and NNP. i.e. a new kernel facility was added precisely to ensure that seccomp cannot be used to run code that is intended to be run privileged – under security policies in control by an unprivileged user. i.e. if you can take certain privs away from code that expects to have them you might be able to trigger vulnerable codepaths that the developer didn't expect you to be able to trigger. But anyway, don't focus so much in cgroups here. There are plenty other props these days that sudo doesn#t clean up. consider this for
Ok, so where's the track record of potential security exploits, in similar kinds of tools, that: 1) leverage any of the resources that you mentioned, and 2) but were mitigated, and became ordinary bugs, thanks to the vulnerable code being an isolated daemon process, with a clean environment.
In absence of an established track record that demonstrates this, in practice, this becomes just a theory. So, I'm not sure that it's clear to me -- is this getting argued based on an established track record, with some data to look at, the shows – based on some basic metrics – the benefits of rewriting suid programs in this manner; or is this just a theoretical argument.
Every additional line of code written to architect a privileged process, in this new manner, is a potential spot for a new bug to grow.
Rolling out a brand-spanking update, with a new architecture, new bootstrapping mechanism, and a new unprivileged process will become a Pyrrhic victory a year later, when it turns out that the privileged process trusted input from the unprivileged process, as an indirect result of new serialization/deserialization code that had to be written. That's where the bulk of the work was. And validating the deserialized data structure was accidentally overlooked.
Or the new serialization/deserialization code has its own buffer overflows. That would be code that didn't exist in the original, monolithic setuid executable.
Attachment:
pgpYOcGm5nXI1.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
