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

[Linus Torvalds]

On Wed, Nov 29, 2017 at 10:30 AM, Kees Cook <keescook at chromium.org> wrote:
> On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>>
>> 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.
>>   [ ... ]
>> Does that sound reasonable?
>
> Yeah, I think I see the way forward here; thanks for the discussion!

Note: I don't want to really force that per-module flag if it ends up
being painful, I was really just thinking that considering the DCCP
case, it would be (I think) a really nice solution.

In particular, request_module() ends up having that indirection
through usermode-helper, which makes it potentially very inconvenient
to store the "did the original caller have proper capabilities" and
then check it at actual module load time.

So the module flag is technically easy to add, and it's technically
easy to read at module loading time, but I suspect that it's actually
annoyingly hard to pass the original request_module() capability
information around to where we actually read the module.

That's why it might be _much_ easier to try to do it per call-site
instead. It's not quite as fine-grained (because several call-sites do
things like

        request_module("net-pf-%d-proto-%d", PF_NETLINK, protocol);

that can load a large number of different modules), but if we can get
away with just saying "this particular callsite is ok, because it only
loads the bluetooth module that we thing is trustworthy" or "this
call-site is ok, because you already had to have access to the device
node", that is going to be much simpler and more straightforward.

In other words: I think there are at least two different models to go
after, and there may be practical reasons to prefer one over the
other.

                    Linus
--
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