On Di, 01.02.22 07:14, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > 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. https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/ I explained a locking DoS there: run privileged code, but with extremly restrictive resource scheduling settings, so that it will acquire privileged resources such as locks (which it can, since it is privileged) but is extremely slow to give up again since it runs awfully slow, due to the extremely restrictive resource settings which are under control of an unpriv caller. > > 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. CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646, CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629, CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, … These are all env var cleanup issues in su/sudo context. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
