bind-chroot obsolete due to SElinux?

Jason Vas Dias jvdias at redhat.com
Sat Mar 4 20:14:39 UTC 2006


On Saturday 04 March 2006 14:49, Ivan Gyurdiev <ivg2 at 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.




More information about the fedora-devel-list mailing list