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.
