Re: RT scheduling and a way to make a process hang, unkillable

[Kyle Moffett <kyle@moffetthome.net>]

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.

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.

Cheers,
Kyle Moffett