| From: |
| Kees Cook <keescook-AT-google.com> |
| To: |
| "Eric W. Biederman" <ebiederm-AT-xmission.com> |
| Subject: |
| user ns: arbitrary module loading |
| Date: |
| Fri, 1 Mar 2013 17:22:44 -0800 |
| Message-ID: |
| <CAGXu5jK7x+gFKgCN5=ZF+kSc4xSNbGtSERHCoOnCEgiJ1_wNGg@mail.gmail.com> |
| Cc: |
| LKML <linux-kernel-AT-vger.kernel.org>,
Serge Hallyn <serge.hallyn-AT-canonical.com>,
Brad Spengler <spender-AT-grsecurity.net>,
Al Viro <viro-AT-zeniv.linux.org.uk> |
| Archive-link: |
| Article, Thread
|
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
--
Kees Cook
Chrome OS Security
(
Log in to post comments)
