2022-02-24 01:02:05

by Andy Lutomirski

[permalink] [raw]
Subject: Re: How should rlimits, suid exec, and capabilities interact?

On Wed, Feb 23, 2022 at 10:00 AM Eric W. Biederman
<[email protected]> wrote:
>
>
> [CC'd the security list because I really don't know who the right people
> are to drag into this discussion]
>
> While looking at some issues that have cropped up with making it so
> that RLIMIT_NPROC cannot be escaped by creating a user namespace I have
> stumbled upon a very old issue of how rlimits and suid exec interact
> poorly.

Once upon a time, these resource limits were effectively the only way
to control memory consumption and consumption of historically limited
resources like processes. (The scheduler used to have serious issues
with too many processes -- this is not so true any more. And without
cgroups, too many processes could use too much CPU collectively.)
This all worked pretty poorly. Now we have cgroups, fancy memory
accounting, etc. So I'm wondering if NPROC is even useful anymore. I
don't have a brilliant idea of how to deprecate it, but I think it
wouldn't be entirely nuts to take it much less seriously and maybe
even eventually get rid of it.

I doubt there is much existing userspace that would break if a
previously failing fork() started succeeding.

--Andy]


2022-02-24 01:28:13

by Willy Tarreau

[permalink] [raw]
Subject: Re: How should rlimits, suid exec, and capabilities interact?

Hi Andy,

On Wed, Feb 23, 2022 at 11:44:51AM -0800, Andy Lutomirski wrote:
> On Wed, Feb 23, 2022 at 10:00 AM Eric W. Biederman
> <[email protected]> wrote:
> >
> >
> > [CC'd the security list because I really don't know who the right people
> > are to drag into this discussion]
> >
> > While looking at some issues that have cropped up with making it so
> > that RLIMIT_NPROC cannot be escaped by creating a user namespace I have
> > stumbled upon a very old issue of how rlimits and suid exec interact
> > poorly.
>
> Once upon a time, these resource limits were effectively the only way
> to control memory consumption and consumption of historically limited
> resources like processes. (The scheduler used to have serious issues
> with too many processes -- this is not so true any more. And without
> cgroups, too many processes could use too much CPU collectively.)
> This all worked pretty poorly. Now we have cgroups, fancy memory
> accounting, etc. So I'm wondering if NPROC is even useful anymore. I
> don't have a brilliant idea of how to deprecate it, but I think it
> wouldn't be entirely nuts to take it much less seriously and maybe
> even eventually get rid of it.
>
> I doubt there is much existing userspace that would break if a
> previously failing fork() started succeeding.

I strongly disagree. I've been using it for a long time as a security
measure. Setting NPROC to 0 after daemonizing remains a particularly
effective and portable method to mitigate the possible consequences of
an in-process intrusion. While I wouldn't care about approximate non-zero
values, for me it would be a significant security regression to drop the
inability to fork() when the limit is zero. Thus at least I do want to
keep that feature when NPROC is zero.

Willy