[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1512110374.28364.33.camel@gmail.com>
Date: Fri, 01 Dec 2017 01:39:34 -0500
From: Daniel Micay <danielmicay@...il.com>
To: Djalal Harouni <tixxdz@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Kees Cook
<keescook@...omium.org>, Jessica Yu <jeyu@...nel.org>, 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>
Subject: Re: Re: [PATCH v5 next 5/5] net: modules: use
request_module_cap() to load 'netdev-%s' modules
It was suggested that the feature would only be adopted in niches like
Android and I pointed out that it's not really relevant to Android.
It's a waste of time to try convincing me that it's useful elsewhere. I
never said or implied that it wasn't.
On Thu, 2017-11-30 at 09:50 +0100, Djalal Harouni wrote:
> On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay <danielmicay@...il.com>
> wrote:
> [...]
> > Lots of potential module attack surface also gets eliminated by
> > default
> > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl
> > commands, etc. The global seccomp whitelist might be relevant in
> > some
> > cases too.
>
> In embedded systems we can't maintain a SELinux policy, distro man
> power hardly manage. We have abstracted seccomp etc, but the kernel
> inherited the difficult multiplex things, plus all other paths that
> trigger this.
It's cheaper to use an existing system like Android Things where device
makers only need to make their apps and perhaps some userspace hardware
drivers for cases not covered by mainline kernel drivers. I don't think
it makes sense for every device vendor to manage an OS and I seriously
doubt that's how the ecosystem is going to end up as it matures.
> > Android devices like to build everything into the kernel too, so
> > even if
> > they weren't using a module this feature wouldn't usually help them.
> > It
> > would need to work like this existing sysctl:
> >
> > net.ipv4.tcp_available_congestion_control = cubic reno lp
> >
> > i.e. whitelists for functionality offered by the modules, not just
> > whether they can be loaded.
>
> Yes, but it is hard to maintain a whitelist policy, the code is hardly
> maintained... if you include everything you should have an LSM policy
> or something like that, and compiling kernels is expert thing.
I'm not talking about whitelist vs. blacklist, compiling kernels or
anything like that.
> Otherwise IMHO the kernel should provide default secure behaviour on
> how to load or add new functionality to the running one. From a user
> perspective, a switch "yes/no" that a privileged entity will
> *understand* and assume is what should be there, and the switch or
> flag as discussed here is local to processes, the sysctl will be
> removed. IMO it should come from userspace point of view, cause as an
> example the sysctl:
>
> net.ipv4.tcp_available_congestion_control = cubic reno lp
>
> Is kernel thing, too technical, userspace developers, admins or
> privileged entity will not understand what cubic or reno mean.
Congestion control algorithms are being used as an example in terms of
the mechanism being used to control which are available to unprivileged
users. The obscurity of congestion control algorithms is irrelevant.
> Doing
> the same per functionality directly like this seems to much of a
> burden compared to the use case. The kernel maybe can do this to
> advance the art of the networking stack and for advanced cases, but in
> IMHO a sane default behaviour + an abstracted process/sandbox flag
> "yes/no" for most others, userspace developers and humans is what
> should be provided and we need the kernel to help here.
There are cases where unprivileged module auto-loading is relied upon
like network protocols. Having configuration for which protocols can be
used by unprivileged users is superior to limiting only which ones can
be auto-loaded. That's why I bought up the existing congestion control
knob. It works well in terms of having a whitelist of the sane, widely
used cases with exposing anything obscure requiring configuration. They
happen to be implemented as modules too.
Killing off unprivileged module loading other than a few cases like that
makes sense, and then those can provide similar control with similarly
sane defaults.
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.
