linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 21 Apr 2010 17:30:59 -0500	[thread overview]
Message-ID: <20100421223059.GA20626@us.ibm.com> (raw)
In-Reply-To: <q2pcb0375e11004211415ge9371513n6fad211823aba2b3@mail.gmail.com>

Quoting Andrew Lutomirski (luto@mit.edu):
> So if we give up on changing nosuid, there are a couple of things we
> might want to do:
> 
> 1. A mode where execve acts like all filesystems are MNT_NOSUID.  This
> sounds like a bad idea (if nothing else, it will cause apps that use
> selinux's exec_sid mechanism (runcon?) to silently malfunction).

I think at this point we've lost track of exactly what we're trying
to do.

The goal, at least for myself and (I think) Eric, was to prevent
certain changes in environment, initiated by an unprivileged user,
from confusing setuid-root programs (initiated by the user).

A concrete example was the proposed disablenet feature, with which
an unprivileged task can remove its ability to open any new network
connections.

With that in mind, I think option 1 is actually the best option.
I especially hate option 2 because of the resulting temptation to
fudge with pE  :)  If you're going to fudge with pE, then IMO it
MUST be done in a new securebits mode.

Now actually, re-reading my msg, given our original goal, I dare
say that Andrew Morgan's approach of simply returning -EPERM for
any app which tries to setuid or change privileges on exec just
might be the sanest way, at least to start with.

-serge

  reply	other threads:[~2010-04-21 22:31 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 [this message]
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

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=20100421223059.GA20626@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).