[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEiveUdrpH4qQnNX_r1EaRaH8jQwO6HsKGRnE1qY+OdCLnkGcw@mail.gmail.com>
Date: Wed, 29 Nov 2017 00:53:16 +0100
From: Djalal Harouni <tixxdz@...il.com>
To: "Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, Djalal Harouni <tixxdz@...il.com>,
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 Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o <tytso@....edu> wrote:
> On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote:
>> As I've said before, this isn't a theoretical attack surface. This
>> year alone there have been three known-exploitable flaws exposed by
>> autoloading:
>>
>> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd,
>> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-"
>> prefix, and is intentionally unprivileged.
>>
>> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP,
>> IPPROTO_IP) [2]. This is using the existing proto prefix, and is
>> intentionally unprivileged.
>
> So in these two cases, if the kernel was built w/o modules, and HDLC
> and DCCP was built-in, you'd be screwed, then?
>
> Is the goal here to protect people using distro kernels which build
> the world as modules, including dodgy pieces of kernel code that are
> bug-ridden?
>
> If so, then presumably 90% of the problem you've cited can be done by
> creating a script which takes a look of the modules that are normally
> in use once the machine is in production, and then deleting everything
> else? Correct?
>
> And yes, this will potentially break some users, but the security
> folks who are advocating for the more aggressive version of this
> change seem to be OK with breaking users, so they can do this without
> making kernel changes. Good luck getting Red Hat and SuSE to accept
> such a change, though....
The patches does not change default and make it easy for users and we
have request for this, not all world is Red Hat / SuSE , I build
embedded Linux for clients when I manage to have some, and I clearly
would have set this to my clients since most of them won't be able to
afford all the signing and complexity, now how I should allow modules
load/unload replace with newer versions, but restrict some of their
apps from triggering it, "modules_disabled=1" is not practical. I
can't build a perfect version for every usecase, and they started to
ship apps for IoT, even containers for IoT, yes they do it and they
use the same os for various use cases! so it is not about those, even
embedded vendors have one single shared layer that they use for all
their products.
For distros, the target is also containers and sandboxes, and they are
already interested in it.
P.S. please the cover letter already mentions that this is for Embedded and IoT.
> - Ted
--
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.
