From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lutomirski Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF Date: Thu, 12 Jan 2012 15:33:47 -0800 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> <1326409536.9705.4.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Kyle Moffett , Linus Torvalds , 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, 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: Eric Paris Return-path: In-Reply-To: <1326409536.9705.4.camel@localhost> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 12, 2012 at 3:05 PM, Eric Paris wrote: > On Thu, 2012-01-12 at 14:08 -0500, Kyle Moffett wrote: >> On Thu, Jan 12, 2012 at 13:44, Andrew Lutomirski wrot= e: >> > On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds wrote: > >> >> 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 abo= ut >> >> this same "restricted environment" bit, and just say that a proce= ss >> >> with that bit set doesn't get to match whatever selinux privilege >> >> escalation rules.. > >> I don't see any issues with SELinux support for this feature. >> >> Specifically, when you try to execute something in SELinux, it will >> first look at the types and try to "execute" (involving a type >> transition IE: security label change). >> >> But if that fails in many cases it may still be allowed to >> "execute_no_trans" (IE: regular non-privileged exec() without a >> transition). > > That's not true. =A0See specifically > security/selinux/hooks.c::selinux_bprm_set_creds() =A0We calculate a = label > for the new task (that may or may not be the same) and then check if > there is permission to run the new binary with the new label. =A0Ther= e is > no fallback. > > The exception would be if the binary is on a MNT_NOSUID mount point, = in > which case we calculate the new label, then just revert to the same > label. > > At first glance it looks to me like a reasonable way to implement thi= s > at first would be to do the new checks right next to any place we > already do MNT_NOSUID checks and mimic their behavior. =A0If there ar= e > other priv escalation points in the kernel we might need to consider = if > MNT_NOSUID is adequate.... > I don't really like the current logic. It does: if (old_tsec->exec_sid) { new_tsec->sid =3D old_tsec->exec_sid; /* Reset exec SID on execve. */ new_tsec->exec_sid =3D 0; } else { /* Check for a default transition on this program. */ rc =3D security_transition_sid(old_tsec->sid, isec->sid= , SECCLASS_PROCESS, NULL, &new_tsec->sid); if (rc) return rc; } COMMON_AUDIT_DATA_INIT(&ad, PATH); ad.u.path =3D bprm->file->f_path; if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) new_tsec->sid =3D old_tsec->sid; which means that, if MNT_NOSUD, then exec_sid is silently ignored. I'd rather fail in that case, but it's probably too late for that. However, if we set the "no new privileges" flag, then we could fail, since there's no old ABI to be compatible with. I'll implement it that way. --Andy -- 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