On Mon, Apr 26, 2010 at 11:19 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/26/2010 10:39 AM, Michal Svoboda wrote:
>> Daniel J Walsh wrote:
>>> First my example was sort of a gross oversimplification. It would not
>>> only effect unconfined_t but any other domain that could use the
>>> setuid bit to gain additional privs.
>>
>> If a domain can use uid=0 to get additional privileges then the MAC
>> policy has holes... like cheese and relies on DAC to plumb them. That
>> significantly reduces the utility of the MAC.
>>
> You have to look at this domain by domain, and the goal of users with
> MAC is to "target" certain domains. 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.
>
>>> unconfined_t to a user means, give him all the power of a normal user
>>> with SELinux disabled. You are still protected by DAC. I would argue
>>> that you want to make sure there are limited setuid apps around when
>>> running with unconfined_t. But if you give him unconfined_t and
>>> "chcon 4755" as a confined user running as root, then you make it
>>> easy for him to become unconfined_t running as UID=0.
>>
>> The problem with this reasoning is thus:
>>
>> 1) you give the user unconfined_t, well, okay, sad but perhaps necessary
>> 2) you give the user root
>> 3) you wonder that the user has root & unconfined
>>
>> I know that the root in (2) is 'bundled in' a MAC restricted domain but
>> since root is a DAC concept it propagates ('leaks') back to the DAC
>> world.
>>
>> You now want the MAC to stop the leak, but IMO that is a futile attempt.
>> It would take some serious analysis to find out how many ways 'root' can
>> leak out. I bet suid is not the only one. How about screwing up the web
>> server so that it runs as root and listens for your commands.
>>
> We are building higher fences around the prison. I am not going for the
> perfect, since this is the enemy of the good. We have lots of domains
> that require DAC privs. It is the combination of DAC and MAC that make
> SELinux powerful. Are goal is not to remove DAC checks in any way.
>>> If we want people to experiment with confined admins, allow unconfined_t
>>> - -> sudo_exec_t -> confined_admin_t is a good thing.
>>
>> People can experiment with confined admins as they like, but they should
>> note that as long as they have an unconfined element in the game the
>> system simply won't be secure. Default allow has never worked.
>>
> 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.
>
> DAC + sudo versus DAC + MAC + SUDO.
I thought that the intent of the current MAC / DAC interaction was
that capabilities are used to decompose root and MAC can restrict
capabilities on processes to add extra DAC protections. Now, I'll
admit a good deal of ignorance here, but is there a reason that we
can't just write policy using that mechanism to accomplish what you
are after? If we prevented confined admin domains with root from
having the needed capability to setuid files isn't that enough? Or if
the right capability doesn't exist, can't you add a new capability?
Karl
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
