Simplicity is a form of art…

In my previous post, a very valid question was raised by Alexander E. Patrakov: why still use chroot if you have SELinux?

Both chroot (especially with the additional restrictions that grSecurity enables on chroots that make it more difficult to break out of a chroot) and SELinux try to isolate an application so it only has access to those resources it needs. Chroot does this on file-level basis (and a bit more with grSecurity), SELinux on more general resources. However, things that make SELinux strong (flexible and detailed policy language, fine-grained authorizations) are also its weakness (consolidating files into groups having the same file label), and chroot does have an advantage on this.

Suppose that a flaw exists in BIND through which an attacker can read files on the host (through BIND). With SELinux, the domain in which BIND runs is prohibited from accessing and reading files whose label is not one of the labels that the policy thinks BIND should be able to read. More specifically, the BIND policy in the reference policy (which is what both Gentoo and RedHat base their policies on, and generally policies are only enlarged, never really shrinked):

• etc_runtime_t (read) means access to the files in /etc that are modified at runtime (like mtab, profile.env, gentoo’s /etc/env.d)
• named_var_run_t (read) is access to /var/run/bind and /var/run/named (and a few other related locations)
• named_checkconf_exec_t (read/execute) is access to read and execute /usr/sbin/named-checkconf
• named_conf_t (read) to read the BIND-related configuration files
• dnssec_t (read) to read the DNSSEC keyfiles
• locale_t (read) to access /etc/localtime, /usr/share/locale/*, /usr/share/zoneinfo/*
• etc_t (read) to read the general configuration files in /etc (including passwd, fstab, …)
• proc_t (read), proc_net_t (read) and sysfs_t (read) to access those pseudo filesystems
• udev_tbl_t (read) to access /dev/.udev and /var/run/udev (but I have no idea yet why this is in)
• named_log_t (read/write) for the log files of BIND
• net_conf_t (read) to access /etc/hosts (including deny/allow), resolv.conf, …
• named_exec_t (read/execute) the BIND executables
• named_zone_t (read) to access the zone files, also write access in case of slave system
• cert_t (read) to read certificate information
• named_cache_t (read/write) to access its cache
• named_tmp_t (read/write) to work with temporary files

Isolation provided by SELinux is as powerful as the width of its labeling. For instance, by giving the named daemon read access to /etc files like passwd, fstab, group, hosts, resolv.conf and more, a malicious user who can exploit this hypothetical vulnerability can obtain information that might help him in his further attempts. By chrooting BIND, the files placed in the chroot itself should not offer the information he might be looking for (for instance, the passwd file, if needed at all, is limited to just the named and root accounts, etc.)

Chrooting, but not enabling SELinux, could lead to escalation. A chroot cannot restrict what a process is allowed to do beyond the regular access privileges that are given on the user. If a user can upload an exploit through BIND and have BIND execute it, he can use this as an attack vector for further activities. SELinux here prohibits BIND to write stuff it can also execute (there is no write and execute privilege defined here). It also ensures that the BIND daemon never exists his security domain (transitioning towards another domain with perhaps other privileges) as there are no transition rules from named_t to any other domain.

Another MAC system that would be better suited to fit both is grSecurity’s RBAC model. Iirc, it uses path definitions to say which files are allowed to access and which not. The weakness SELinux here has (aggregation into sets of files with the same label) doesn’t exist for grSecurity. This debate on path-based versus label-based access controls have been going on for very long time now – just google it ;-)

So, Alexander, in short: chroot further limits the SELinux-allowed privileges to a more fine-grained set of file system resources (files/directories).

BIND, or Berkeley Internet Name Domain, is one of the Internet’s most popular domain name service software (DNS). It has seen its set of security flaws in the past, which is not that strange as it is such a frequently used service on the Internet. In this post, I’ll give a quick intro on how to use it in Gentoo Hardened (with PaX)… chrooted… for IPv6… with SELinux ;-)

Installing is of course, as usual, dead easy on Gentoo (Hardened/SELinux). Make sure you have USE=”ipv6″ set, and then emerge bind. Also install bind-tools as they contain some great tools to help with DNS troubleshooting. Then we’re editing /etc/conf.d/named to set the CHROOT variable. I also set CHROOT_NOMOUNT so that Gentoo doesn’t bind-mount the information in the chroot but instead uses the files in the chroot.

CHROOT="/var/named/chroot"
CHROOT_NOMOUNT="1"

Now we need to either temporarily add some privileges in SELinux, or run the portage_t domain in permissive mode. If you go for privileges, then add the following:

allow portage_t var_t:chr_file { create getattr setattr };

If you however want to temporarily run the portage_t domain in permissive mode, do that as follows:

~# semanage permissive -a portage_t

We are doing this because we are now going to ask the BIND ebuild to prepare the chroot for us. Doing so however requires portage to work on our live file system (and not in the regular “sandbox” mode). SELinux however forces portage in the portage_t domain and only gives it the privileges it needs for building and installing software.

~# emerge --config bind

When done, remove the previous SELinux allow rules again (or set the portage_t domain back in enforcing mode, through semanage permissive -d portage_t). Next we need to relabel the files in the chroot. By default, all files are labeled by SELinux as var_t in that location because it isn’t aware that it needs to see /var/named/chroot as a “root” location.

~# setfiles -r /var/named/chroot /etc/selinux/strict/contexts/files/file_contexts /var/named/chroot

So far so good. Now let’s create a simple named.conf file (in /var/named/chroot/etc/bind):

options {
  directory "/var/bind";
  pid-file "/var/run/named/named.pid";
  statistics-file "/var/run/named/named.stats";
  listen-on { 127.0.0.1; };
  listen-on-v6 { 2001:db8:81:21::ac:98ad:5fe1; };
  allow-query { any; };
  zone-statistics yes;
  allow-transfer { 2001:db8:81:22::ae:6b01:e3d8; };
  notify yes;
  recursion no;
  version "[nope]";
};

# Access to DNS for local addresses (i.e. genfic-owned)
view "local" {
  match-clients { 2001:db8:81::/48; };
  recursion yes;
  zone "genfic.com" { type master; file "pri/com.genfic"; };
  zone "1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "pri/inv.com.genfic"; };
};

The zone files referenced in the configuration file are located in /var/named/chroot/var/bind (in a subdirectory called pri – which I use for “primary”). The regular one would look similar to this:

$TTL 1h ;
$ORIGIN genfic.com.
@       IN      SOA     ns.genfic.com. ns.genfic.com. (
                        2012041101
                        1d
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.
        IN      MX      10      mail.genfic.com.
        IN      MX      20      mail2.genfic.com.

genfic.com.     IN      AAAA    2001:db8:81:80::dd:13ed:c49e;
ns              IN      AAAA    2001:db8:81:21::ac:98ad:5fe1;
ns2             IN      AAAA    2001:db8:81:22::ae:6b01:e3d8;
www             IN      CNAME   genfic.com.;
mail            IN      AAAA    2001:db8:81:21::b0:0738:8ad5;
mail2           IN      AAAA    2001:db8:81:22::50:5e9f:e569;
; (...)

while the one for reverse lookups looks like so:

$TTL 1h ;
@       IN      SOA     1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.genfic.com. (
                        2012041101
                        1d
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.

$ORIGIN 1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

1.e.f.5.d.a.8.9.c.a.0.0.0.0.0.0.1.2.0.0         IN      PTR     ns.genfic.com.
8.d.3.e.1.0.b.6.e.a.0.0.0.0.0.0.2.2.0.0         IN      PTR     ns2.genfic.com.
; (...)

We can now start the init script:

~# rc-service named start

On the slave, don’t set the allow-transfer directive and set its type to “slave”. In each zone, you will need to tell where the master is:

zone "genfic.com" {
  type slave;
  masters { 2001:db8:81:21::ac:98ad:5fe1; }
  file "sec/com.genfic";
};

By default, the SELinux policy for BIND does not allow BIND to write stuff in its directories. On the slave system, you will need to change this. A SELinux boolean here does the trick:

~# setsebool -P named_write_master_zones on;

There ya go ;-) Okay, all very condensely written, but it should give some feedback on how to proceed. I’m adding this information to the new online resource I’m writing – A Gentoo Linux Advanced Reference Architecture. Nothing really ready yet, just writing as I go forward with exploring these technologies…