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...
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.
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.