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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Feb 2009 15:16:25 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Corey Hickey <bugfood-ml@...ooh.org>,
	linux-kernel@...r.kernel.org,
	Bharata B Rao <bharata@...ux.vnet.ibm.com>,
	Balbir Singh <balbir@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>, mtk.manpages@...il.com
Subject: Re: RT scheduling and a way to make a process hang, unkillable

On Mon, Feb 16, 2009 at 5:36 AM, Dhaval Giani <dhaval@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/