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 devel
mailing list