mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lutomirski <luto@mit.edu>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>,
	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 11:53:29 -0400	[thread overview]
Message-ID: <s2pcb0375e11004200853m62ee45b5lf447da1e1a55ffc5@mail.gmail.com> (raw)
In-Reply-To: <1271777652.30027.131.camel@moss-pluto.epoch.ncsc.mil>

On Tue, Apr 20, 2010 at 11:34 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> True,  but I think it's still asking for trouble -- other LSMs could
>> (and almost certainly will, especially the out-of-tree ones) do
>> something, and I think that any action at all that an LSM takes in the
>> bprm_set_creds hook for a nosuid (or whatever it's called) process is
>> wrong or at best misguided.
>>
>> Can you think of anything that an LSM should do (or even should be
>> able to do) when a nosuid process calls exec, other than denying the
>> request outright?  With my patch, LSMs can still reject the open_exec
>> call.
>
> In the case where the context transition would shed permissions rather
> than gain permissions, it has been suggested that we shouldn't disable
> the transition even in the presence of nosuid.  But automatically
> computing that for a domain transition is non-trivial, so we have the
> present behavior for SELinux.
>
> There also can be state updates even in the non-suid exec case, e.g.
> saved uids, clearing capabilities, etc.

Ah, right.

In my patch, execve_nosecurity is (or will be, anyway) documented to
skip all of this, and it's a new syscall, so nothing should need to be
done.  It doesn't allow anything that a userland ELF loader couldn't
already do.  (I'm not thrilled with changing the behavior of the
original execve syscall, but one way or another, any nosuid mechanism
will probably allow programs to exec other things without losing
permissions that the admin might have expected.  I don't see this is a
real problem, though.)

Is it even possible to purely drop permissions in SELinux?  If your
original type was orig_t and your new type is new_t, and if the rights
granted to orig_t and new_t overlap nontrivially, then what are you
supposed to do?  Check both types for each hook?  (Some annoying admin
could even *change* the rights for orig_t or new_t after execve
finishes.)

>
> But as far as the access control goes, it should suffice to check read
> and execute access to the file, just as with the userland ELF loader
> scenario (which gets handled by the mmap hook).
>
> --
> Stephen Smalley
> National Security Agency
>
>

  reply	other threads:[~2010-04-20 15:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-26 13:38 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 [this message]
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=s2pcb0375e11004200853m62ee45b5lf447da1e1a55ffc5@mail.gmail.com \
    --to=luto@mit.edu \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=serge@hallyn.com \
    --cc=serue@us.ibm.com \
    /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

Powered by JetHome