Lennart Poettering writes:
On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > 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. I already described you a vulnerability. And the vulnerabilities in
I must've missed those descriptions. Is there a reference somewhere that I can read, which describes them.
sudo from not cleaning up env vars are pretty well documented, too no? And they are the same kind: not cleaned up context.
A basic search finds the most recent sudo exploit was a heap based buffer overflow in sudo about a year ago. Something that can equally happen in an isolated process, too, if triggered the same way.
A more careful search located the sudo exploit you described, from 2014, CVE-2014-0106. I couldn't find anything similar in sudo's history, so this must be what you are referring to. Looks like it was in a non-default configuration, and after reading up the details of the exploit:
The only argument I see here, is that if the isolated process-based implementation of an sudo-alternative did not implement the non-env_reset option in the first place. If it did implement the non-env_reset related option, presumably there would've been some mechanism for the client to transmit its environment to the isolated process, for the benefit of the spawned subshell.
And it that turned out to be the case, the same exact bug would've happened. The process isolation would not've accomplished anything, here. The problem was not inherent with an suid-based approach. sudo had a broken implemenation of an optional configuration setting. If it was broken in the same way, in an isolated process, the lack of the setuid bit would not've made any material difference.
Attachment:
pgpIracfT1jG8.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
