From: Linus Torvalds > Sent: 24 February 2022 01:42 > > On Wed, Feb 23, 2022 at 5:24 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > > > Question: Running a suid program today charges the activity of that > > program to the user who ran that program, not to the user the program > > runs as. Does anyone see a problem with charging the user the program > > runs as? > > So I think that there's actually two independent issues with limits > when you have situations like this where the actual user might be > ambiguous. > > - the "who to charge" question > > - the "how do we *check* the limit" question > > and honestly, I think that when it comes to suid binaries, the first > question is fundamentally ambiguous, because it almost certainly > depends on the user. Doesn't the rlimit check happen during the fork. At which time you don't know that a suid exec might follow? The problem with changing the uid is that when the process exits you need to "uncharge" the correct uid. So either you need to remember the original uid or setuid has to transfer the charge (whichever uid is used). If you transfer the charge then the setuid system call can't fail. But a later exec can fail. Any check will always be done against the process's own rlimit value. Set that to zero and fork should fail regardless of which uid's process count is checked. Now a normal suid program only changes the effective uid. So keeping the process charged against the real uid makes sense. If a process changes its real uid you could change the charged uid but you can't error if over the rlimit value. OTOH during a later exec you can test things and exec can fail. At least one unix I've used has three uids for each process. The 'real uid', 'effective uid' and 'saved by exec uid'. I suspect the process is always "charged" against the latter. I think that exec compares the 'real' and 'saved by exec' uids and, if different, moves the charge to the real uid (which will check rlimit) then sets the 'saved by exec uid' to the real uid. So an exec after a setuid() can be allowed to fail if the real user has too many processes. But in all other cases exec just works regardless of the process count for any user. > > Which to me implies that there probably isn't an answer that is always > right, and that what you should look at is that second option. > > So I would actually suggest that the "execute a suid binary" should > charge the real user, but *because* it is suid, it should then not > check the limit (or, perhaps, should check the hard limit?). > > You have to charge somebody, but at that point it's a bit ambiguous > whether it should be allowed. > > Exactly so that if you're over a process limit (or something similar - > think "too many files open" or whatever because you screwed up and > opened everything) you could still log in as yourself (ssh/login > charges some admin thing, which probably has high limits or is > unlimited), and hopefully get shell access, and then be able to "exec > sudo" to actually get admin access that should be disabled from the > network. You usually have to use 'rsh machine sh -i' to avoid the shell running all its startup scripts. But I doubt that will get you past a fork bomb. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
