From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427098AbdDUXwi (ORCPT ); Fri, 21 Apr 2017 19:52:38 -0400 Received: from nm19-vm1.bullet.mail.ne1.yahoo.com ([98.138.91.56]:55928 "EHLO nm19-vm1.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1427081AbdDUXwe (ORCPT ); Fri, 21 Apr 2017 19:52:34 -0400 X-Yahoo-Newman-Id: 428986.36910.bm@smtp222.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HOfim80VM1m.V2OuAGDOzaasqPniwL2K4k8OeTS9cRPZrK0 iwIWijU_RKJgc4peF8dQD1zK3tpjeitNkh_gjda69UPWZbZrKtJhnsWkDp6. 7PZa84szCN93Iqy.dmG4E5gtaP1c1UcsQ1.kNAMPYnW6KF2KIRhv9v_4L0i8 30JFv4Mgrti.P4MduPrQFktxcSJ8blbVUqOrr9qwwLLSZY2Jg51B3GEV7tqu bhimcOz_88icPCFpZi8bExIQi86G8tSSYXLx2jw0YRUCPmdib6fyKzgzrgE6 V7Maw5yb.taCr7iKeGOm1tKz0JmmvA8CoE.iDG9H2Q1g0tJobEm7HA9B4DEe 1Ck30_ioKaHgfIUibYokjb3X9_syGL0ZfZMpZhLnQNTKF.6VKdjvb_B60B.T BRBLNSTDWuBlril02cT80vYglVxdaVRAawIL4kjcVFnhEnCHETSLcjGlykAE g3F8HKbLBjClr71RAaO2_VacOZ9eWlP8q01tfwoTtNViJ6.3zZdBPX8LYNTA ZEMSPDj_n4ClW X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction To: Andy Lutomirski , Kees Cook References: <1492640420-27345-1-git-send-email-tixxdz@gmail.com> <1492640420-27345-3-git-send-email-tixxdz@gmail.com> Cc: Andy Lutomirski , Djalal Harouni , Linux Kernel Mailing List , Andrew Morton , "Serge E. Hallyn" , "kernel-hardening@lists.openwall.com" , LSM List , Linux API , Dongsu Park , James Morris , Paul Moore , Tetsuo Handa , Greg Kroah-Hartman , Jonathan Corbet , Jessica Yu , Rusty Russell , Arnaldo Carvalho de Melo , Mauro Carvalho Chehab , Ingo Molnar , belakhdar abdeldjalil , Peter Zijlstra From: Casey Schaufler Message-ID: <5f07b121-62e1-b9a8-4faa-f6630b24ff48@schaufler-ca.com> Date: Fri, 21 Apr 2017 16:52:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/21/2017 4:28 PM, Andy Lutomirski wrote: > On Fri, Apr 21, 2017 at 4:19 PM, Kees Cook wrote: >> On Wed, Apr 19, 2017 at 7:41 PM, Andy Lutomirski wrote: >>> On Wed, Apr 19, 2017 at 4:43 PM, Kees Cook wrote: >>>> On Wed, Apr 19, 2017 at 4:15 PM, Andy Lutomirski wrote: >>>>> On Wed, Apr 19, 2017 at 3:20 PM, Djalal Harouni wrote: >>>>>> +/* Sets task's modules_autoload */ >>>>>> +static inline int task_set_modules_autoload(struct task_struct *task, >>>>>> + unsigned long value) >>>>>> +{ >>>>>> + if (value > MODULES_AUTOLOAD_DISABLED) >>>>>> + return -EINVAL; >>>>>> + else if (task->modules_autoload > value) >>>>>> + return -EPERM; >>>>>> + else if (task->modules_autoload < value) >>>>>> + task->modules_autoload = value; >>>>>> + >>>>>> + return 0; >>>>>> +} >>>>> This needs to be more locked down. Otherwise someone could set this >>>>> and then run a setuid program. Admittedly, it would be quite odd if >>>>> this particular thing causes a problem, but the issue exists >>>>> nonetheless. >>>> Eeeh, I don't agree this needs to be changed. APIs provided by modules >>>> are different than the existing privilege-manipulation syscalls this >>>> concern stems from. Applications are already forced to deal with >>>> things being missing like this in the face of it simply not being >>>> built into the kernel. >>>> >>>> Having to hide this behind nnp seems like it'd reduce its utility... >>>> >>> I think that adding an inherited boolean to task_struct that can be >>> set by unprivileged tasks and passed to privileged tasks is a terrible >>> precedent. Ideally someone would try to find all the existing things >>> like this and kill them off. >> (Tristate, not boolean, but yeah.) >> >> I see two others besides seccomp and nnp: >> >> PR_MCE_KILL > Well, that's interesting. That should presumably be reset on setuid > exec or something. > >> PR_SET_THP_DISABLE > Um. At least that's just a performance issue. > >> I really don't think this needs nnp protection. >> >>> I agree that I don't see how one would exploit this particular >>> feature, but I still think I dislike the approach. This is a slippery >>> slope to adding a boolean for perf_event_open(), unshare(), etc, and >>> we should solve these for real rather than half-arsing them IMO. >> I disagree (obviously); this would be protecting the entire module >> autoload attack surface. That's hardly a specific control, and it's a >> demonstrably needed flag. >> > The list is just going to get longer. We should probably have controls for: > > - Use of perf. Unclear how fine grained they should be. > > - Creation of new user namespaces. Possibly also use of things like > iptables without global privilege. > > - Ability to look up tasks owned by different uids (or maybe other > tasks *at all*) by pid/tid. Conceptually, this is easy. The API is > the only hard part, I think. > > - Ability to bind ports, maybe? One of my longer term (i.e. after stacking) projects is to create sensible access control on ports. Why shouldn't they have owners and mode bits (or ACLs, if you prefer) or real names. I kind of think we should be able to eliminate the need for dbus without resorting to kdbus. So I don't like the idea of treating that as a special case. I'd rather see ports controlled properly. (Of course, the SELinux crowd will point out they have this handled, but I remain unconvinced of the overall solution) > > My point is that all of these need some way to handle configuration > and inheritance, and I don't think that a bunch of per-task prctls is > the right way. As just an example, saying that interactive users can > autoload modules but other users can't, or that certain systemd > services can, etc, might be nice. Linus already complained that he > (i.e. user "torvalds" or whatever) should be able to profile the > kernel but that other uids should not be able to. > > I personally like my implicit_rights idea, and it might be interesting > to prototype it. > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >