From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754893Ab2ALSov (ORCPT ); Thu, 12 Jan 2012 13:44:51 -0500 Received: from mail-gy0-f174.google.com ([209.85.160.174]:38713 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752177Ab2ALSos convert rfc822-to-8bit (ORCPT ); Thu, 12 Jan 2012 13:44:48 -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> From: Andrew Lutomirski Date: Thu, 12 Jan 2012 10:44:27 -0800 X-Google-Sender-Auth: BaD1H6_7ByYBobvU2gMoUO0CPLQ Message-ID: Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF To: Linus Torvalds Cc: Steven Rostedt , Will Drewry , 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 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. execve_nosecurity was my attempt to sidestep selinux issues. It's a different syscall that does all of the non-security-related things that execve does but does not escalate (or even change) any privileges. Maybe I'll try to rework that for newer kernels as well. The idea is that programs that expect to run in sandboxes / chroots / namespaces / whatever can use it, and older programs that might malfunction dangerously if the semantics of execve change will just fail instead. --Andy