bind-chroot obsolete due to SElinux?

Ivan Gyurdiev ivg2 at cornell.edu
Sat Mar 4 19:49:20 UTC 2006


> Yes
>
> There's no protection provided by bind-chroot that is not provided by running
> named with SELinux in Enforcing mode.
>   
I have my doubts about that.

A chroot jail allows you to easily see what bind can and cannot do.
SElinux requires analysis of policy to accomplish the same thing.
It likely does have a lot more privileges than when jailed.

For example,
files_read_etc_files(named_t) allows named to read all files marked 
etc_t. Those are usually configuration files, shouldn't be any secrets 
there.... What if it turns out there is a secret file mislabeled by 
mistake? Why is named interested in configuration of other programs anyway?

I also see named can interact with NetworkManager, mount(??), dbus 
domain over sockets and pipes.
Is this possible in a chroot jail?

To be sure the application does exactly what it should, it's necessary to:
1) look at the generated policy, and search for dangerous domain 
interactions.
2) ensure labeling is working properly

I would advise people working on bind-chroot to audit the selinux policy 
and make sure it does what it should, before assuming it provides the 
same level of confinement as a chroot jail. SElinux does aim for minimum 
privilege - but to what degree it accomplishes that is highly variable 
depending on which policy you're looking at. That's probably why SELinux 
runs after DAC, and not by itself.




More information about the fedora-devel-list mailing list