From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751821AbdK2Saf (ORCPT ); Wed, 29 Nov 2017 13:30:35 -0500 Received: from mail-ua0-f195.google.com ([209.85.217.195]:41716 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751558AbdK2Sac (ORCPT ); Wed, 29 Nov 2017 13:30:32 -0500 X-Google-Smtp-Source: AGs4zMYVseTOwNFclpYWAqAle2EvQZoY0yvBjyplo3O8m6WZXM7vDb59M2tje8NgmF7h7PDS/V4UD6Z+GNSmFHqbtC4= MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> <708003731.69563.1511905898471@ichabod.co-bxl> From: Kees Cook Date: Wed, 29 Nov 2017 10:30:30 -0800 X-Google-Sender-Auth: U_ynVMXThvQCO2_n0PGwTqNiaVA Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules To: Linus Torvalds Cc: Geo Kozey , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook 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. > > Does that sound reasonable? Yeah, I think I see the way forward here; thanks for the discussion! -Kees -- Kees Cook Pixel Security