Disclaimer: This post was originally posted in 2008 as an article on the now-defunct website zazzybob.com. While the software version and actual commands used may vary, the concepts are still similar and give a general idea of how to approach a given problem.
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
|
1 2 |
# named -v BIND 9.2.4 |
First, create a named group
|
1 |
# groupadd named |
Next, add a named user. After testing, you should set the shell to /bin/false or similar.
|
1 2 |
# 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
|
1 |
# svcs -a | grep 'dns/server' |
If not, disable it
|
1 |
# svcadm disable svc:/network/dns/server:default |
Create your chroot tree (note: you do not need to create dev and populate it)
|
1 2 3 4 |
# 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.
|
1 2 3 |
# 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
|
1 |
# chown -R named:named /var/named |
Check that you can run named in your chroot environment as the named user
|
1 |
# /usr/sbin/named -c /etc/named.conf -t /var/named -u named |
Create a copy of the server manifest
|
1 2 |
# 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# 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 on a single line in your xml files!
Next, validate your new xml manifest:
|
1 2 |
# 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:
|
1 |
# svccfg import /var/svc/manifest/network/dns/server-chroot.xml |
Check that the import was successful:
|
1 2 |
# svcs -a | grep chroot # svcs -xv server-chroot |
Good, now we can enable the service, and test that it’s running:
|
1 2 3 |
# 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. Bringing 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.