From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Kees Cook <keescook@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Brad Spengler <spender@grsecurity.net>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: user ns: arbitrary module loading
Date: Sat, 02 Mar 2013 20:12:22 -0800 [thread overview]
Message-ID: <874ngtxgt5.fsf@xmission.com> (raw)
In-Reply-To: <20130303005700.GA32213@austin.hallyn.com> (Serge E. Hallyn's message of "Sat, 2 Mar 2013 18:57:00 -0600")
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Kees Cook (keescook@google.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).
CAP_SETUID is not needed.
>> 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.
What is wrong with GRKERNSEC_MODHARDEN? It took a quick look and the
code is far from clean. But that would not be a fundamental objection
from keeping code like that out of the kernel.
It is also entertaining to read security code that won't even build with
CONFIG_UIDGID_STRICT_TYPE_CHECKS enabled.
> 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?
The obvious solution here is to test for CAP_SYS_ADMIN rather than
current_user_ns == &init_user_ns before we request the module here. As
that is what was previously required on this path.
Reading the comments the concerns are.
- Non-root users are allowed to load obscure and possibly kernel
modules.
- get_fs_type can trigger the load of any kernel module.
At a practical level I don't see adding a capalbe(CAP_SYS_ADMIN) check
as having much effect for the functionality currently present in user
namespaces today as the filesystems that an legal to mount in a user
namespace (ramfs, tmpfs, mqueuefs, sysfs, proc, devpts) are so common
most of them can not even be built as modules and even if they are
modules the modules will already be loaded. So I will see about adding
a capable(CAP_SYS_ADMIN) check to shore things up for the short term.
In the longer term I very much would like to get loopback devices
and mounts of filesystems on those loopback devices working, and being
able to mount filesystems from usb sticks that people commonly plug in,
and remove the need for privileged daemons to do that work. At that
point manually having to do something that was automatic before will
either mean a regression in functionality or bugs as people manually
load things.
So I am wondering what I a good policy should be. Should we trust
kernel modules to not be buggy (especially if they were signed as part
of the build process)? Do we add some defense in depth and add
filesystem registration magic? Thinking...
We can limit the request_module in get_fs_type to just filesystems
fairly easily.
In include/linux/fs.h:
#define MODULE_ALIAS_FS(type) MODULE_ALIAS("fs-" __stringify(type))
In fs/filesystems.c:
if (request_moudle("fs-%.*s", len, name) == 0)
Then just add the appropriate MODULE_ALIAS_FS lines in all of the
filesystems. This also allows user space to say set the module loading
policy for filesystems using the blacklist and the alias keywords
in /etc/modprobe.d/*.conf.
That seems a whole lot simpler, more powerful and more maintainable than
what little I saw in GRKERNSEC_MODHARDEN to prevent loading of
non-filesystem modules from get_fs_type.
Eric
p.s. This is the patch I am looking at pushing to Linus in the near
future.
diff --git a/fs/filesystems.c b/fs/filesystems.c
index da165f6..5b0644d 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -273,7 +273,8 @@ struct file_system_type *get_fs_type(const char *name)
int len = dot ? dot - name : strlen(name);
fs = __get_fs_type(name, len);
- if (!fs && (request_module("%.*s", len, name) == 0))
+ if (!fs && capable(CAP_SYS_ADMIN) &&
+ (request_module("%.*s", len, name) == 0))
fs = __get_fs_type(name, len);
if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
next prev parent reply other threads:[~2013-03-03 4:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-02 1:22 user ns: arbitrary module loading Kees Cook
2013-03-03 0:57 ` Serge E. Hallyn
2013-03-03 1:18 ` Kees Cook
2013-03-03 3:56 ` Serge E. Hallyn
2013-03-03 10:14 ` [RFC][PATCH] fs: Limit sys_mount to only loading filesystem modules Eric W. Biederman
2013-03-03 15:29 ` Serge E. Hallyn
2013-03-03 18:30 ` Kees Cook
2013-03-03 17:48 ` user ns: arbitrary module loading Kees Cook
2013-03-04 8:29 ` Mathias Krause
2013-03-04 16:46 ` Kees Cook
2013-03-04 18:21 ` Eric W. Biederman
2013-03-04 18:41 ` Kees Cook
2013-03-03 4:12 ` Eric W. Biederman [this message]
2013-03-03 18:18 ` Kees Cook
2013-03-03 21:58 ` Eric W. Biederman
2013-03-04 2:35 ` Kees Cook
2013-03-04 3:54 ` Eric W. Biederman
2013-03-04 7:48 ` [PATCH 0/2] userns bug fixes for v3.9-rc2 for review Eric W. Biederman
2013-03-04 7:50 ` [PATCH 1/2] userns: Stop oopsing in key_change_session_keyring Eric W. Biederman
2013-03-04 7:51 ` [PATCH 2/2] fs: Limit sys_mount to only request filesystem modules Eric W. Biederman
2013-03-04 17:36 ` Vasily Kulikov
2013-03-04 18:36 ` Eric W. Biederman
2013-03-05 19:06 ` Kay Sievers
2013-03-05 19:32 ` Kees Cook
2013-03-05 23:24 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ngtxgt5.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.com \
--cc=spender@grsecurity.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox