[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrV7wjxz-V6u7mduBadULbP7z13WgJAWg+i_nNGxpnPqPQ@mail.gmail.com>
Date: Thu, 6 Jul 2017 08:30:04 -0700
From: Andy Lutomirski <luto@...nel.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Kees Cook <keescook@...omium.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>,
Michal Hocko <mhocko@...nel.org>,
Ben Hutchings <ben@...adent.org.uk>, Willy Tarreau <w@....eu>,
Hugh Dickins <hughd@...gle.com>,
Oleg Nesterov <oleg@...hat.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...hat.com>,
Larry Woodman <lwoodman@...hat.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Tony Luck <tony.luck@...el.com>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Helge Diller <deller@....de>,
James Hogan <james.hogan@...tec.com>,
Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
"security@...nel.org" <security@...nel.org>,
Qualys Security Advisory <qsa@...lys.com>,
LKML <linux-kernel@...r.kernel.org>,
Ximin Luo <infinity0@...ian.org>
Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec
On Thu, Jul 6, 2017 at 5:38 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Kees Cook <keescook@...omium.org> writes:
>
>> In an attempt to provide sensible rlimit defaults for setuid execs, this
>> inherits the namespace's init rlimits:
>>
>> $ ulimit -s
>> 8192
>> $ ulimit -s unlimited
>> $ /bin/sh -c 'ulimit -s'
>> unlimited
>> $ sudo /bin/sh -c 'ulimit -s'
>> 8192
>>
>> This is modified from Brad Spengler/PaX Team's hard-coded setuid exec
>> stack rlimit (8MB) in the last public patch of grsecurity/PaX based on
>> my understanding of the code. Changes or omissions from the original
>> code are mine and don't reflect the original grsecurity/PaX code.
>>
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> ---
>> Instead of copying all rlimits, we could also pick specific ones to copy
>> (e.g. RLIMIT_STACK, or ones from Andy's list) or exclude from copying
>> (probably better to blacklist than whitelist).
>>
>> I think this is the right way to find the ns init task, but maybe it
>> needs locking?
>> ---
>> fs/exec.c | 34 ++++++++++++++++++++++++++++++----
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 904199086490..80e8b2bd4284 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1675,6 +1675,12 @@ static int exec_binprm(struct linux_binprm *bprm)
>> return ret;
>> }
>>
>> +static inline bool is_setuid_exec(struct linux_binprm *bprm)
>> +{
>> + return (!uid_eq(bprm->cred->euid, current_euid()) ||
>> + !gid_eq(bprm->cred->egid, current_egid()));
>> +}
>
> Awesome I can make an executable setuid to myself and get all of roots
> rlimits!
>
> Scratch inheritable rlimits as useful for any kind of policy decision.
Most of them are already fairly useless. But it's a fair point. We
don't want Jane to run a setuid-John program and thereby escape
whatever limits are imposed. We don't really have a concept of
bona-fide-trustworthy-setuid-root, though.
Powered by blists - more mailing lists