On Saturday 04 March 2006 14:49, Ivan Gyurdiev <i...@cornell.edu> wrote: > > > 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. Not so - any infractions by named are clearly logged, which would not be the case if running in bind-chroot with SELinux disabled. > It likely does have a lot more privileges than when jailed. > Not so - except in the etc_t case you mention. > 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? > This is because named.conf can 'include "...";' other files, which are in $ROOTDIR/etc and not labelled as named_conf_t by default - unless in the chroot, where /var/named/chroot/etc/* is labelled as named_conf_t. I think probably this should be changed to label /etc/named.* or /etc/bind/* as named_conf_t and disallow named etc_t read privilege. But this is mitigated by the fact that named runs as the 'named:named' user, and most /etc/* files should be -rw------- . > I also see named can interact with NetworkManager, mount(??), dbus > domain over sockets and pipes. > Is this possible in a chroot jail? > Yes - named by default is given the '-D' command line option to enable dbus support for dynamic forwarder table management, which NetworkManager uses. That means the init script needs to mount /var/run/dbus in the chroot. This is easily disabled by removing the -D option from the /etc/sysconfig/named 'OPTIONS=-D' setting. Also, the named initscript still needs to mount /proc under the chroot to determine the correct number of CPUs, and in order to respond to changes in the interface list.
named does not need to have mount privileges - only the initscript needs them. > 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. > The bind-chroot environment exists primarily to prevent named modifying files it should not be able to, if taken over or compromised. This is also accomplished sufficiently well by the SELinux policy. Also ExecShield, -z noexecstack, and read-only relocation segments are enabled for the named executable, making it extremely difficult if not impossible to take over a running named process. So I think SELinux protection is enough for named . Regards, Jason Vas Dias.
