Solaris 10 BIND Chroot

Introduction

The default BIND installation in Solaris 10 does not run in a chroot environment, which is an obvious security risk. Starting BIND to run in a chroot environment is a no-brainer, but getting it to managed by SMF in Solaris 10 requires a bit more work...

Configuration

We're using the bundled version of BIND for this

    
# named -v
BIND 9.2.4
    
    

First, create a named group

    
# groupadd named
    
    

Next, add a named user. After testing, you should set the shell to /bin/false or similar.

    
# useradd -m -d /var/named -c "BIND User" -s /bin/bash -g named named
# passwd named
    
    

Check that the standard dns/server:default service is disabled

    
# svcs -a | grep 'dns/server'
    
    

If not, disable it

    
# svcadm disable svc:/network/dns/server:default
    
    

Create your chroot tree (note: you do not need to create dev and populate it)

    
# mkdir -p /var/named/var/named
# mkdir /var/named/var/log
# mkdir /var/named/var/run
# mkdir /var/named/etc
    
    

Run rndc-confgen and use the output to populate your /var/named/etc/rndc.key and /var/named/etc/named.conf files. Also, enter any configuration into your named.conf as required.

    
# rndc-confgen
# vi /etc/rndc.key /var/named/etc/named.conf
# ln -s /etc/rndc.key /var/named/etc/rndc.key
       
    

Change ownership of the chroot tree

    
# chown -R named:named /var/named
   
    

Check that you can run named in your chroot environment as the named user

    
# /usr/sbin/named -c /etc/named.conf -t /var/named -u named
   
    

Create a copy of the server manifest

    
# cd /var/svc/manifest/network/dns
# cp -p server.xml server-chroot.xml
   
    

You'll need to make a few modifications to the server-chroot.xml file. The following diff shows the edits required:

    
# diff /var/svc/manifest/network/dns/server{,-chroot}.xml
13c13
< name='network/dns/server'
---
> name='network/dns/server-chroot'
57c57
<    <service_fmri value='file://localhost/etc/named.conf' />
---
>    <service_fmri value='file://localhost/var/named/etc/named.conf' />
63c63
<    exec='/usr/sbin/named'
---
>    exec='/usr/local/sbin/named -c /etc/named.conf -t /var/named -u named'
75,77c75,77
<    user='root'
<    group='root'
<    privileges='basic,!proc_session,!proc_info,!file_link_any,
        net_privaddr,file_dac_read,file_dac_search,sys_resource' />
---
>    user='named'
>    group='named'
>    privileges='basic,!proc_session,!proc_info,!file_link_any,net_privaddr,
        priv_proc_chroot,priv_file_dac_read,file_dac_search,sys_resource'  />
   
    

NOTE: The privileges lines have been SPLIT FOR CLARITY only in the output above, and should be one a SINGLE LINE in your xml files!

Next, validate your new xml manifest

    
# xmllint -valid /var/svc/manifest/network/dns/server-chroot.xml
# svccfg validate /var/svc/manifest/network/dns/server-chroot.xml
   
    

Now, the manifest can be imported into SMF

    
# svccfg import /var/svc/manifest/network/dns/server-chroot.xml
   
    

Check that the import was successful

    
# svcs -a | grep chroot
# svcs -xv server-chroot
      
    

Good, now we can enable the service, and test that it's running

    
# svcadm enable server-chroot
# svcs -xv server-chroot
# ps -ef | grep named
       
    

If things do not work as expected, check the service log (/var/svc/log/network-dns-server-chroot:default.log) as well as /var/adm/messages, and your BIND logs if you've enabled logging.

Conclusion

SMF provides a great deal of fault tolerance (and guards against human error) but can make major modifications to existing services tricky. Brining BIND into a chroot, whilst still having it under SMF control (and not reverting to init.d scripts) takes a bit of work, but is worth it.

Cheers
Kevin Waldron
kevin@zazzybob.com

Disclaimer! - This article is provided for guidance only, and does not replace the relevant official documentation and manuals. I will not be held liable for any hosed systems and/or data.

Valid CSS!

Valid HTML 4.01!