[kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

[Eric W. Biederman]

Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook <keescook at chromium.org> wrote:
>>
>>> The model that I am a proponent of is to take a softer approach
>>> initially: don't forbid module loading (because that breaks users),
>>> but instead _warn_ about non-root module loading. And then we can
>>> start fixing the cases that we find.
>>
>> I am totally fine with this. The question I'm hoping to have answered
>> is, "then what?" We already have concrete examples of module
>> autoloading that will still be need to stay unprivileged and as-is in
>> the kernel (even if we remove others). What do you see as the way to
>> allow an admin to turn those off?
>
> Just thinking about the DCCP case, where networking people actually
> knew it was pretty deprecated and had no real maintainer, I think one
> thing to look at would be simply a per-module flag.
>
> That kind of thing should be fairly easy to implement, along the same
> lines as the module license - it just sets a flag in the ELF section
> headers.
>
> With something like that, we literally could make the default be "no
> autoloading except for root", and then just mark the modules that we
> think are ok and well maintained.
>
> Sure, if you then do a lock-down mode that makes that flag parsing
> stricter, then that's a separate thing. But I suspect we definitely
> could be a lot stricter on a per-module basis, and do it in a way
> where a normal user wouldn't even notice that we've limited the
> autoloading.
>
> But the first step would be to just add some noise. And even with the
> per-module flag, at first it would only suppress the noise (ie we'd
> still _allow_ loading other modules, they'd just be noisy). Then, if
> nobody hollers, maybe the next kernel release we'll make it actually
> enforce the flag.
>

On a slight tangent to all of this.

The issue of reducing attack surface has also come up in another thread
and it was suggested there that we make some ns_capable calls
conditionally capable calls so certain pieces of code won't be available
in user namespaces, when we know there is a bug but don't yet have a
good fix rolled out yet.

Which again brings us to attack surface reduction.

I was wondering if perhaps a better way to do some of that, might be to
have places in the kernel where we could use something like ftrace to
add a permission check at a well known functions boundaries and fail the
functions when we want to reduce the attack surface.

It is not as elegant as adding a maintenance status to a module and only
allowing actively maintained modules to be auto-loaded.  But perhaps
with a few more eyes the idea can be fleshed out to something generally useful.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html