[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Mar 2013 18:57:00 -0600
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Kees Cook <keescook@...gle.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
LKML <linux-kernel@...r.kernel.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
Brad Spengler <spender@...ecurity.net>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: user ns: arbitrary module loading
Quoting Kees Cook (keescook@...gle.com):
> The rearranging done for user ns has resulted in allowing arbitrary
> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
> by what is assumed to be an unprivileged process.
>
> At present, it does look to require at least CAP_SETUID along the way
> to set up the uidmap (but things like the setuid helper newuidmap
> might soon start providing such a thing by default).
>
> It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which
> examines module symbols to verify that request_module() for a
> filesystem only loads a module that defines "register_filesystem"
> (among other things).
>
> -Kees
>
> [1] https://twitter.com/grsecurity/status/307473816672665600
So the concern is root in a child user namespace doing
mount -t randomfs <...>
in which case do_new_mount() checks ns_capable(), not capable(),
before trying to load a module for randomfs.
As well as (secondly) the fact that there is no enforcement on
the format of the module names (i.e. fs-*).
Kees, from what I've seen the GRKERNSEC_MODHARDEN won't be acceptable.
At least Eric Paris is strongly against it. But how about if we
add a check for 'current_user_ns() == &init_user_ns' at that place
instead?
Eric Biederman, do you have any objections to that?
thanks,
-serge
--
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/
Powered by blists - more mailing lists