linux-kernel - Re: [PATCH] Reserve N process to root

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 for Android: free password hash cracker in your pocket

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

Message-Id: <200710120002.37341.a1426z@gawab.com>
Date:	Fri, 12 Oct 2007 00:02:37 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Reserve N process to root

David Newall wrote:
> Valdis.Kletnieks@...edu wrote:
> > What David meant was that "root will always have a slot" doesn't
> > *actually* help unless you *also* have a way to actually *spawn* such a
> > process.  In order to do the ps, kill, and so on that you need to
> > recover, you need to already have either a root shell available, or a
> > way to *get* a root shell that doesn't rely on a non-root process (so
> > /bin/su doesn't help here).
>
> That's right, although it's worse than that.  You need to have a process
> with CAP_SYS_ADMIN.  If root processes normally have that capability
> then the reserved slots may well disappear before you notice a problem.
> If root processes normally don't have it, then you need to guarantee
> that one is already running.

I once posted a patch to handle this DoS, but, as usual, it wasn't accepted.  
Go figure...

Here is an excerpt:

Re: [PATCH 1/1] threads_max: Simple lockout prevention patch

From: Al Boldi <a1426z@...ab.com>
To: Andrew Morton <akpm@...l.org>
CC: linux-kernel@...r.kernel.org
Date: 04/24/06 02:12 pm

Andrew Morton wrote:
> Al Boldi <a1426z@...ab.com> wrote:
> > This is a another resend, which was ignored before w/o comment.
> > Andrew, can you at least comment on it?  Thanks!
>
> I don't have a clue what it's for.

Quoting from the 'Resource limits' thread on lkml on 27/09/05:
>>>>> Consider this dilemma:
>>>>> Runaway proc/s hit the limit.
>>>>> Try to kill some and you are denied due to the resource limit.
>>>>> Use some previously running app like top, hope it hasn't been killed
>>>>> by some OOM situation, try killing some procs and another one takes
>>>>> it's place because of the runaway situation.
>>>>> Raise the limit, and it gets filled by the runaways.
>>>>> You are pretty much stuck.
>>>>
>>>> Not really, this is the sort of thing ulimit is meant for.  To keep
>>>> processes from any one user from running away.  It lets you limit the
>>>> damage it can do, until such time as you can control it and fix the
>>>> runaway application.
>>>
>>> threads-max = 1024
>>> ulimit = 100 forks
>>> 11 runaway procs hitting the threads-max limit
>>
>> This is incorrect.  If you ulimit a user to 100 forks, and 11 processes
>> running with that uid
> 
> Different uid.
> 
Then yes, if you set a system-wide limit that is less than the sum of the 
limits imposed on each accountable part of the system you can have lock out.  
But thats your fault for misconfiguring the system.  Don't do that.

-- end of quote

Thanks!

--
Al

-
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/