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

On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds
[off-list ref] wrote:

On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook [off-list ref] wrote:

quoted

So what's the right path forward for allowing a way to block
autoloading? Separate existing request_module() calls into "must be
privileged" and "can be unpriv" first, then rework the series to deal
with the "unpriv okay" subset?

So once we've taken care of the networking ones that check their own
different capability bit, maybe we can then make the regular
request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses
that prints which module it's loading.

Alright, I can start by those.

And then just see what people report.

Because maybe it's just a very small handful that matters, and we can
say "those are ok".

The ones that are in the cover letter, etc may not have the
appropriate context, the request_module_dev() sure can be made since
if you can open you already have the context.

And maybe that is too optimistic, and we have a lot of device driver
ones because people still have a static /dev and don't have udev
populating modules and device nodes, and then maybe we need to
introduce a "request_module_dev()" where the rule is that you had to
at least have privileges to open the device node.

Because I really am *not* interested in these security flags that are
off by default and then get turned on by special cases. I think it's
completely unacceptable to say "we're insecure by default but then you
can do X and be secure". It doesn't work. It doesn't fix anything.

this still leaves all the cases where we don't have the appropriate
context and other implicit loads that are triggered by another
implicit load, etc.

Also the simple local flag is easy to grasp, with real users for it,
and we can abstract on top with load "newfeatures" of course this does
not mean that we should say "we-re insecure by default". I want it to
be more allow newfeatures or not for apps and users... requiring caps
may give users the idea to pass CAP_SYS_MODULE or other caps for
something that used to work, they may start giving it if we break lot
of usecases, and yeh the caps are much broader and do much more
harm...

Ok, so beside updating with request_module_cap() I will investigate
request_module_dev() and we can see

Thanks!

                 Linus

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