Quoting Kees Cook (keesc...@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).
>
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
