[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jul 2011 09:14:08 +1000
From: NeilBrown <neilb@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Vasiliy Kulikov <segoon@...nwall.com>,
linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
kernel-hardening@...ts.openwall.com, Jiri Slaby <jslaby@...e.cz>,
James Morris <jmorris@...ei.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] move RLIMIT_NPROC check from set_user() to
do_execve_common()
On Tue, 12 Jul 2011 14:16:10 -0700 Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Jul 12, 2011 at 6:27 AM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> >
> > The NPROC can still be enforced in the common code flow of daemons
> > spawning user processes. Most of daemons do fork()+setuid()+execve().
> > The check introduced in execve() enforces the same limit as in setuid()
> > and doesn't create similar security issues.
>
> Ok, this looks fine by me. I'd like to get some kind of comment from
> the selinux etc people (James?) but I'd certainly be willing to take
> this.
>
> Failing when executing a suid application rather than when a suid
> application releases its heightened credentials seems to be the
> fundamentally saner approach. IOW, failing to raise privileges rather
> than failing to lower them.
>
> Linus
I am happy with the patch in general - it adequately addresses the problem
which I fixed by adding the test to set_user which is now being removed.
However I don't think your characterisation is quite correct Linus.
There is no setuid application, and there is no raising of privileges.
The contrast is really "failing when trying to use reduced privileges is
safer than failing to reduce privileges - if the reduced privileges are not
available".
Note that there is room for a race that could have unintended consequences.
Between the 'setuid(ordinary-user)' and a subsequent 'exit()' after execve()
has failed, any other process owned by the same user (and we know where are
quite a few) would fail an execve() where it really should not.
I think it would be safer to add a test for PF_SUPERPRIV and PF_FORKNOEXEC
in current->flags and only fail the execve if both are set.
i.e.
(current->flags & (PF_SUPERPRIV|PF_FORKNOEXEC)) == (PF_SUPERPRIV|PF_FORKNOEXEC)
That should narrow it down to only failing in the particular case that we are
interested in.
NeilBrown
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.
