From: Daniel J Walsh <dwalsh@redhat.com>
To: selinux@tycho.nsa.gov
Subject: Re: [PATCH] SELINUX: new permission controlling the ability to set suid
Date: Wed, 28 Apr 2010 13:32:42 -0400 [thread overview]
Message-ID: <4BD8713A.3060702@redhat.com> (raw)
In-Reply-To: <20100428161813.GC1622@myhost.felk.cvut.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/28/2010 12:18 PM, Michal Svoboda wrote:
> Daniel J Walsh wrote:
>> If we went full lock down on every domain then we would not have > 70%
>> of the fedora community running with SELinux enabeled in enforcing
>> mode.
>
> I hear you and I still believe this was/is a smart choice, but I think
> with your proposal you're not adhering to its spirit.
>
> If unconfined means equal to DAC then the unconfined user should be able
> to become unconfined root even if via seteuid backdoor. If you want to
> prevent this then you're confining the user. (You're now _targeting_
> that ability.)
>
> So here's an idea: why not just make an unconfined_user_t that would be
> stripped of root powers so that even if it becomes euid 0 he could not
> exercise them. Then just control the ways of unconfined_user_t becoming
> unconfined_admin_t (for example, type transition on trusted seteuid
> executable program files).
>
> Seems to me much simpler and much more bulletbroof than removing _one_
> possible way of many by what you proposed - that is confining an already
> confined admin, which is only very remotely responsible for what you
> want to avoid.
>
>> This is not default allow. It is DAC + MAC as opposed to the way most
>> people run, which is just DAC. I am trying to make setattr check better.
>
> Note that from MAC viewpoint, DAC is remarkably similar to default allow.
>
>
> Michal Svoboda
Well in a way this is what staff_t is, a user which can run most apps
without a problem. but when it runs an app that requires capabilities,
it needs to transition to another domain. staff_t is what I run on my
laptop. The problem is staff_t < unconfined_t in that it can not run
apps that require capabilities that someone has not written policy for.
Admin installs a third party app that requires setuid/setgid or some
other priv, now he needs to write policy to transition his staff_t to
thirdparty_t. In my scenario, unconfined_t will be able to run the
third party app, and will be able to becom confinedadmin_t for some sudo
jobs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvYcToACgkQrlYvE4MpobOlJQCeMYi4JDYBIdlo5hYeA2WZGEPT
NvAAoKta0qd51FFAGJWhB40r1KPQNmTB
=xSvm
-----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.
next prev parent reply other threads:[~2010-04-28 17:32 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
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 [this message]
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=4BD8713A.3060702@redhat.com \
--to=dwalsh@redhat.com \
--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.