From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Eric Biederman <ebiederm@xmission.com>,
"Andrew G. Morgan" <morgan@kernel.org>
Subject: Re: [PATCH 0/3] Taming execve, setuid, and LSMs
Date: Tue, 20 Apr 2010 21:25:46 -0500 [thread overview]
Message-ID: <20100421022546.GA23877@us.ibm.com> (raw)
In-Reply-To: <v2ocb0375e11004201837ib470c98dj9fea78d2d75799df@mail.gmail.com>
Quoting Andrew Lutomirski (luto@mit.edu):
> On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> >> Quoting Andrew Lutomirski (luto@mit.edu):
> >> > 1. LSM transitions already scare me enough, and if anyone relies on
> >> > them working in concert with setuid, then the mere act of separating
> >> > them might break things, even if the "privileged" (by LSM) app in
> >> > question is well-written.
> >>
> >> hmm...
> >>
> >> A good point.
> >
> > At least in the case of SELinux, context transitions upon execve are
> > already disabled in the nosuid case, and Eric's patch updated the
> > SELinux test accordingly.
>
> I don't see that code in current -linus, nor do I see where SELinux
> affects dumpability. What's supposed to happen? I'm writing a patch
> right now to clean this stuff up.
check out security/selinux/hooks.c:selinux_bprm_set_creds()
if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
new_tsec->sid = old_tsec->sid;
I assume that's it?
-serge
prev parent reply other threads:[~2010-04-21 2:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 13:38 [PATCH 0/3] Taming execve, setuid, and LSMs Andy Lutomirski
2010-03-26 13:38 ` [PATCH 1/3] Add the execve_nosecurity syscall Andy Lutomirski
2010-03-26 13:38 ` [PATCH 2/3] Add PR_RESTRICT_ME to disable security-sensitive features for a process tree Andy Lutomirski
2010-03-26 13:38 ` [PATCH 3/3] Add PR_SET_FORCE_EXECVE_NOSECURITY to turn execve calls into execve_nosecurity Andy Lutomirski
2010-04-19 17:26 ` [PATCH 0/3] Taming execve, setuid, and LSMs Serge E. Hallyn
2010-04-19 21:32 ` Andrew Lutomirski
2010-04-19 21:39 ` Serge E. Hallyn
2010-04-19 22:02 ` Andrew Lutomirski
2010-04-19 22:25 ` Serge E. Hallyn
2010-04-20 12:37 ` Stephen Smalley
2010-04-20 14:23 ` Andrew Lutomirski
2010-04-20 14:35 ` Serge E. Hallyn
2010-04-20 15:11 ` Andrew Lutomirski
2010-04-21 21:15 ` Andrew Lutomirski
2010-04-21 22:30 ` Serge E. Hallyn
2010-04-21 23:42 ` Andy Lutomirski
2010-04-20 15:34 ` Stephen Smalley
2010-04-20 15:53 ` Andrew Lutomirski
2010-04-21 12:34 ` Stephen Smalley
2010-04-21 1:37 ` Andrew Lutomirski
2010-04-21 2:25 ` Serge E. Hallyn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100421022546.GA23877@us.ibm.com \
--to=serue@us.ibm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@mit.edu \
--cc=morgan@kernel.org \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.