Messages in this thread | | | Date | Tue, 17 Feb 2009 12:52:28 +0530 | From | Dhaval Giani <> | Subject | Re: RT scheduling and a way to make a process hang, unkillable |
| |
On Mon, Feb 16, 2009 at 03:16:25PM -0500, Kyle Moffett wrote: > On Mon, Feb 16, 2009 at 5:36 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote: > > On Sun, Feb 15, 2009 at 12:24:56PM +0100, Peter Zijlstra wrote: > >> On Sat, 2009-02-14 at 16:51 -0800, Corey Hickey wrote: > >> > The procedure is for a program to: > >> > 1. run as root > >> > 2. set SCHED_FIFO > >> > 3. change UID to a user with no realtime CPU share allocated > >> > >> Hmm, setuid() should fail in that situation. > >> > >> /me goes peek at code. > >> > >> Can't find any code to make that happen, Dhaval didn't we fix that at > >> one point? > > > > So after some searching around, I realized we did not. Does this help? > > It fixes it on my system, > > > > -- > > sched: Don't allow setuid to succeed if the user does not have rt bandwidth > > Erm, hrm, this reminds me of the old sendmail capabilities bug. There > are an awful lot of buggy binaries out there who assume that if they > have uid 0 and they call setuid() that it cannot fail. They then do > all sorts of insecure operations, assuming that they have dropped to > an unprivileged UID. This one is especially bad because it could bite > *any* program using setuid() which an admin happens to run with chrt. >
Would that not be a bug in the application itself and fixed there itself? As Peter mentions there are other ways setuid can fail as well.
> Specifically, I personally think that: > * Process is stuck and unkillable > > is a much better result than: > * Process runs arbitrary untrusted code with full-root privs in RT mode. >
thanks, -- regards, Dhaval
| |