All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@redhat.com>, selinux@tycho.nsa.gov, jmorris@namei.org
Subject: Re: [PATCH] SELINUX: new permission controlling the ability to set suid
Date: Fri, 23 Apr 2010 08:03:58 -0400	[thread overview]
Message-ID: <4BD18CAE.4050201@redhat.com> (raw)
In-Reply-To: <1271972155.16202.55.camel@moss-pluto.epoch.ncsc.mil>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/22/2010 05:35 PM, Stephen Smalley wrote:
> On Thu, 2010-04-22 at 16:46 -0400, Eric Paris wrote:
>> This patch adds a new permission, setsuid, to the file class.  This
>> permission is checked any time a file has its attributes modified
>> (setattr) and the setuid or setgid bits are involved.  The purpose for
>> this change is to further allow selinux to confine administrative
>> duties.
>>
>> This permission is needed to both set the setuid bit and to add more
>> permissions to a file which already has setuid bit.  This is also checked
>> when an acl is modified on a file containing the suid or sgid bit.  We
>> do not know if the acl is more or less restrictive, so we always check
>> the permission on acl changes.
> 
> Can you help us all remember why you want this permission?  Specific use
> case example, what threat you are mitigating, why it is sufficiently
> important to justify an entirely new permission dedicated to it.
> 
> If we add this permission for this purpose, why wouldn't we also add
> distinct permissions for other DAC purposes, e.g. suid-root vs.
> suid-nonroot, suid vs sgid, sticky bit, setting vs clearing, making a
> file executable, ...?  Where does it stop?
> 
> I'm also not keen on overloading it to also cover other changes to the
> mode/ACL.  Presumably that is to constrain extending execute access to
> an existing suid file more widely than originally set?  Write access
> should kill suid/sgid bits.  Read access is perhaps a concern, but
> relying on unreadable executables isn't a good idea.
> 
> Can you write a description of this permission and how it differs from
> setattr permission in a way that will make sense to a typical Linux
> admin?  
> 
>> Signed-off-by: Eric Paris <eparis@redhat.com>

My original thinking on this was a way to separate out Confined Root
Admin from user.

One possible use case would be.  I want to allow a user to login as
unconfined_t and only be able to become root as webadm_t through sudo.

If webadm_t has setattr on /var/www, he can cp /bin/sh /var/www/sh,
chcon 4755 /var/www/sh, exit webadm_t and as unconfined_t become root
using /var/www/sh.

I think your other examples are valid, but I believe setuid/setgid
applications have always been considered much more of a problem then the
others.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvRjK4ACgkQrlYvE4MpobOw6wCeLY0Yn5eLQu9hibHrTYLAqVex
IMIAn2P7S1lobPS21eAjOL/dBwua5R0K
=K0Xx
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2010-04-23 12:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 20:46 [PATCH] SELINUX: new permission controlling the ability to set suid Eric Paris
2010-04-22 21:35 ` Stephen Smalley
2010-04-23 12:03   ` Daniel J Walsh [this message]
2010-04-23 13:51     ` Stephen Smalley
2010-04-26  6:18     ` Michal Svoboda
2010-04-26 12:52       ` Daniel J Walsh
2010-04-26 14:39         ` Michal Svoboda
2010-04-26 15:19           ` Daniel J Walsh
2010-04-28 14:32             ` Karl MacMillan
2010-04-28 15:39               ` Daniel J Walsh
2010-04-28 17:57                 ` Karl MacMillan
2010-04-28 18:07                   ` Stephen Smalley
2010-04-28 18:31                     ` Karl MacMillan
2010-04-28 18:41                       ` Daniel J Walsh
2010-04-28 18:45                       ` Stephen Smalley
2010-04-28 16:18             ` Michal Svoboda
2010-04-28 17:32               ` Daniel J Walsh
2010-04-28 18:54                 ` Michal Svoboda
2010-04-28 19:02                   ` Daniel J Walsh

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=4BD18CAE.4050201@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@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.