From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752508AbdK2E0r (ORCPT ); Tue, 28 Nov 2017 23:26:47 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:48971 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751528AbdK2E0o (ORCPT ); Tue, 28 Nov 2017 23:26:44 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Kees Cook , Geo Kozey , LSM List , Linux Kernel Mailing List , "kernel-hardening\@lists.openwall.com" , Mahesh Bandewar (=?utf-8?B?4KSu?= =?utf-8?B?4KS54KWH4KS2IOCkrOCkguCkoeClh+CkteCkvuCksA==?=) , "Serge E. Hallyn" 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> Date: Tue, 28 Nov 2017 22:26:32 -0600 In-Reply-To: (Linus Torvalds's message of "Tue, 28 Nov 2017 16:50:09 -0800") Message-ID: <87o9nlk8w7.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1eJtxE-0004mo-R1;;;mid=<87o9nlk8w7.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.248.7;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+TDg6aV4+uxlC/3moigaJMNQfOKx820Tg= X-SA-Exim-Connect-IP: 67.3.248.7 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_04 7+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_05 8+ unique symbols in subject X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 5568 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.0 (0.1%), b_tie_ro: 2.0 (0.0%), parse: 1.51 (0.0%), extract_message_metadata: 32 (0.6%), get_uri_detail_list: 3.8 (0.1%), tests_pri_-1000: 14 (0.2%), tests_pri_-950: 2.2 (0.0%), tests_pri_-900: 1.83 (0.0%), tests_pri_-400: 42 (0.7%), check_bayes: 39 (0.7%), b_tokenize: 14 (0.3%), b_tok_get_all: 11 (0.2%), b_comp_prob: 6 (0.1%), b_tok_touch_all: 3.1 (0.1%), b_finish: 0.86 (0.0%), tests_pri_0: 1631 (29.3%), check_dkim_signature: 1.04 (0.0%), check_dkim_adsp: 5 (0.1%), tests_pri_500: 3833 (68.8%), poll_dns_idle: 3822 (68.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > 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. > 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