Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jun 2012 02:22:41 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: owl-dev@...ts.openwall.com
cc: kernel-hardening@...ts.openwall.com
Subject: Re: RLIMIT_NPROC DoS fix

On Tue, 12 Jun 2012, Vasily Kulikov wrote:

> There is a problem with RLIMIT_NPROC patch:
> http://www.openwall.com/lists/kernel-hardening/2011/06/12/9

I'd like to point out there are at least two other ways setuid() et alii 
can fail in recent kernels: LSM and memory allocation.

> 1) a root process sometimes does setrlimit()+setuid(U)+execve()/fork().
> In this case U can do kill(pid, SIGSTOP) each time just after setuid(U).
> U may store unlimited number of processes this way.
> (Spender has learned this way.)

You could probably refuse to handle SIGSTOP sent by a nonprivileged user 
when PF_NPROC_EXCEEDED is set. I do not thing it would break anything.
But it would make things even dirtier.

> 2) there are nonroot users A and B.
> A makes a binary ./loop which does setuid(A)+for(;;) {}
> A does chmod u+s ./loop
> B does 'while :; do ./loop &; done'

I think processes should count towards RLIMIT_NPROC of the user who forked 
them (B in this example) for the rest of their CPU cycles. Even after they 
exec a setuid program.

> Yes, this is dirty.  Any thoughts about less dirty way?

Create a cgroup controller limiting the number of tasks (and perhaps the 
number of other kernel objects) and pretend RLIMIT_NPROC has never 
existed?

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.