From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755164Ab2ALTnB (ORCPT ); Thu, 12 Jan 2012 14:43:01 -0500 Received: from mail-bk0-f46.google.com ([209.85.214.46]:62773 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755103Ab2ALTm5 convert rfc822-to-8bit (ORCPT ); Thu, 12 Jan 2012 14:42:57 -0500 MIME-Version: 1.0 In-Reply-To: References: <1326302710-9427-1-git-send-email-wad@chromium.org> <1326302710-9427-2-git-send-email-wad@chromium.org> <1326383015.7642.77.camel@gandalf.stny.rr.com> <1326385635.7642.89.camel@gandalf.stny.rr.com> Date: Thu, 12 Jan 2012 13:42:55 -0600 Message-ID: Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF From: Will Drewry To: Andrew Lutomirski Cc: Linus Torvalds , Steven Rostedt , linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, oleg@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 12, 2012 at 1:40 PM, Will Drewry wrote: > On Thu, Jan 12, 2012 at 12:44 PM, Andrew Lutomirski wrote: >> On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds >> wrote: >>> On Thu, Jan 12, 2012 at 10:18 AM, Andrew Lutomirski wrote: >>>> >>>> Like this? >>>> >>>> http://lkml.indiana.edu/hypermail/linux/kernel/1003.3/01225.html >>> >>> I don't know the execve_nosecurity patches, so the diff makes little >>> sense to me, but yeah, I wouldn't expect it to be more than a couple >>> of lines. Exactly *how* you set the bit etc is not something I care >>> deeply about, prctl seems about as good as anything. >>> >>>> Note that there's a huge can of worms if execve is allowed but >>>> suid/sgid is not: selinux may elevate privileges on exec of pretty >>>> much anything.  (I think that this is a really awful idea, but it's in >>>> the kernel, so we're stuck with it.) >>> >>> You can do any amount of crazy things with selinux, but the other side >>> of the coin is that it would also be trivial to teach selinux about >>> this same "restricted environment" bit, and just say that a process >>> with that bit set doesn't get to match whatever selinux privilege >>> escalation rules.. >>> >>> I really don't think this is just about "execve cannot do setuid". I >>> think it's about the process being marked as restricted. >>> >>> So in your patch, I think that "PR_RESTRICT_EXEC" bit is wrong. It >>> should simply be "PR_RESTRICT_ME", and be done with it, and not try to >>> artificially limit it to be some "execve feature", and more think of >>> it as a "this is a process that has *no* extra privileges at all, and >>> can never get them". >> >> Fair enough.  I'll submit the simpler patch tonight. > > This sounds cool.  Do you think you'll go for a new task_struct member > or will it a securebit?  (Seems like securebits might be too tied to > posix file caps, but I figured I'd ask). Or cred member, etc. > I'm planning on going ahead and mocking up your potential patch so I > can respin this series using it and make sure I understand the > interactions. > > thanks! > will From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Drewry Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF Date: Thu, 12 Jan 2012 13:42:55 -0600 Message-ID: References: <1326302710-9427-1-git-send-email-wad@chromium.org> <1326302710-9427-2-git-send-email-wad@chromium.org> <1326383015.7642.77.camel@gandalf.stny.rr.com> <1326385635.7642.89.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linus Torvalds , Steven Rostedt , linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, oleg@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com To: Andrew Lutomirski Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 12, 2012 at 1:40 PM, Will Drewry wrote: > On Thu, Jan 12, 2012 at 12:44 PM, Andrew Lutomirski wr= ote: >> On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds >> wrote: >>> On Thu, Jan 12, 2012 at 10:18 AM, Andrew Lutomirski = wrote: >>>> >>>> Like this? >>>> >>>> http://lkml.indiana.edu/hypermail/linux/kernel/1003.3/01225.html >>> >>> I don't know the execve_nosecurity patches, so the diff makes littl= e >>> sense to me, but yeah, I wouldn't expect it to be more than a coupl= e >>> of lines. Exactly *how* you set the bit etc is not something I care >>> deeply about, prctl seems about as good as anything. >>> >>>> Note that there's a huge can of worms if execve is allowed but >>>> suid/sgid is not: selinux may elevate privileges on exec of pretty >>>> much anything. =A0(I think that this is a really awful idea, but i= t's in >>>> the kernel, so we're stuck with it.) >>> >>> You can do any amount of crazy things with selinux, but the other s= ide >>> of the coin is that it would also be trivial to teach selinux about >>> this same "restricted environment" bit, and just say that a process >>> with that bit set doesn't get to match whatever selinux privilege >>> escalation rules.. >>> >>> I really don't think this is just about "execve cannot do setuid". = I >>> think it's about the process being marked as restricted. >>> >>> So in your patch, I think that "PR_RESTRICT_EXEC" bit is wrong. It >>> should simply be "PR_RESTRICT_ME", and be done with it, and not try= to >>> artificially limit it to be some "execve feature", and more think o= f >>> it as a "this is a process that has *no* extra privileges at all, a= nd >>> can never get them". >> >> Fair enough. =A0I'll submit the simpler patch tonight. > > This sounds cool. =A0Do you think you'll go for a new task_struct mem= ber > or will it a securebit? =A0(Seems like securebits might be too tied t= o > posix file caps, but I figured I'd ask). Or cred member, etc. > I'm planning on going ahead and mocking up your potential patch so I > can respin this series using it and make sure I understand the > interactions. > > thanks! > will -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html