|
Message-ID: <87o9nlk8w7.fsf@xmission.com> Date: Tue, 28 Nov 2017 22:26:32 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Kees Cook <keescook@...omium.org>, Geo Kozey <geokozey@...lfence.com>, LSM List <linux-security-module@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "kernel-hardening\@lists.openwall.com" <kernel-hardening@...ts.openwall.com>, Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com>, "Serge E. Hallyn" <serge@...lyn.com> Subject: Re: Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Linus Torvalds <torvalds@...ux-foundation.org> writes: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook <keescook@...omium.org> wrote: >> >>> The model that I am a proponent of is to take a softer approach >>> initially: don't forbid module loading (because that breaks users), >>> but instead _warn_ about non-root module loading. And then we can >>> start fixing the cases that we find. >> >> I am totally fine with this. The question I'm hoping to have answered >> is, "then what?" We already have concrete examples of module >> autoloading that will still be need to stay unprivileged and as-is in >> the kernel (even if we remove others). What do you see as the way to >> allow an admin to turn those off? > > 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. > > That kind of thing should be fairly easy to implement, along the same > lines as the module license - it just sets a flag in the ELF section > headers. > > With something like that, we literally could make the default be "no > autoloading except for root", and then just mark the modules that we > think are ok and well maintained. > > Sure, if you then do a lock-down mode that makes that flag parsing > stricter, then that's a separate thing. But I suspect we definitely > could be a lot stricter on a per-module basis, and do it in a way > where a normal user wouldn't even notice that we've limited the > autoloading. > > But the first step would be to just add some noise. And even with the > per-module flag, at first it would only suppress the noise (ie we'd > still _allow_ loading other modules, they'd just be noisy). Then, if > nobody hollers, maybe the next kernel release we'll make it actually > enforce the flag. > On a slight tangent to all of this. The issue of reducing attack surface has also come up in another thread and it was suggested there that we make some ns_capable calls conditionally capable calls so certain pieces of code won't be available in user namespaces, when we know there is a bug but don't yet have a good fix rolled out yet. Which again brings us to attack surface reduction. I was wondering if perhaps a better way to do some of that, might be to have places in the kernel where we could use something like ftrace to add a permission check at a well known functions boundaries and fail the functions when we want to reduce the attack surface. It is not as elegant as adding a maintenance status to a module and only allowing actively maintained modules to be auto-loaded. But perhaps with a few more eyes the idea can be fleshed out to something generally useful. Eric
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.