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.
> 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.
> 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.
Simply put I don't like this from systemic sense, but perhaps the demand
is so high that you should go ahead (with a big fat red warning).
Michal Svoboda
Attachment:
pgpHayDK9SP3y.pgp
Description: PGP signature
