[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEiveUehNyZ3mFwzvuu1fj87_37QR+rRyQ9pBLzj-V6yshP1-g@mail.gmail.com>
Date: Tue, 28 Nov 2017 22:10:24 +0100
From: Djalal Harouni <tixxdz@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <keescook@...omium.org>, "Theodore Ts'o" <tytso@....edu>,
Jonathan Corbet <corbet@....net>, James Morris <james.l.morris@...cle.com>,
LSM List <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Geo Kozey <geokozey@...lfence.com>
Subject: Re: 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
<torvalds@...ux-foundation.org> wrote:
> On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook <keescook@...omium.org> wrote:
>>
>> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
