Detections
Analytics

8 - Run BIND as a non-root user

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

To start BIND in Linux you must execute it as the root user. For Solaris, this is not necessary as it can be started as any user with the appropriate privileges for proper operation. BIND has the ability to change users, allowing it to drop the root privileges

Rationale:

The reason for configuring BIND to run as a non-root user is to limit the impact in case a future vulnerability is discovered and exploited. This is a common practice, which implements the principal of least privilege. This principle states that an entity, such as a service or user, should be granted only those specific privileges necessary to perform authorized actions. The server will still need to be started as root, but it should be configured to give up the root privilege after listening on port 53. The user named runs as needs to be created if it does not already exist and needs appropriate access to the DNS configuration and data files. Many systems including Red Hat Linux will come with a named user already created. Usage of the user and group id of 53 in the examples is arbitrary but is intended to be easier to recognize as it matches the listening port number.

Solution

Create named user and group if it does not already exist. Using a shell of /dev/null is best practice.
if ! id named; then
groupadd -g 53 named
useradd -m -u 53 -g 53 -c 'BIND named' -d /var/named -s /dev/null named
fi 2>/dev/null
In Solaris, consider using roleadd(1M) to create the named account instead of using useradd(1M). Creating the account as a role adds protections should a password ever be installed: (1) the account still cannot be accessed remotely - even with a correct password and (2) roles can only be assumed by those users who have been granted access.
Also, usermod(1m) dictates that UID's 0 through 99 are reserved for the operating systems use, therefore the use of the UID 53 will produce an error. To correct this, you should choose a UID that is outside of its reserved range. Also, it recommended that /dev/null not be used as a shell. Instead, the Solaris 10 benchmark recommends that the shell be set to /usr/bin/false, and the account be set to locked (passwd -l) or non-login (passwd -N).
if ! id named; then
groupadd -g 153 named
roleadd -m -u 153 -g 153 -c 'BIND named' -d /var/named -s /usr/bin/false named
passwd -l named
fi 2>/dev/null
In Linux, add or verify that -u named option is included in the rc startup script. For
example, the rc script is /etc/rc.d/init.d/named and should contain the line 'daemon /usr/sbin/$PROG -u named ${OPTIONS};'
Red Hat / Fedora Core Linux with Bastille
If you use the Bastille-Linux security hardening, the script will ask, if it detects BIND is installed, 'Would you like to chroot named and set it to run as a non-root user?'
Answering Yes to this question can help automate this step as well as the chroot process, however you still need to verify all of the permissions and verify that the chroot directory contains the necessary devices, directories and files.
Solaris 10
Solaris 10 uses a different approach to configure the BIND service to run as a non-root user. It should first be noted however, that the BIND service in Solaris 10 is already configured to run with significantly reduced privileges. This is accomplished with Solaris 10 privileges(5) and configured using SMF. To see what privileges are granted to BIND at service startup, use the following command:
$ svcprop -p start/privileges dns/server basic,!proc_session,!proc_info,!file_link_any,net_privaddr, file_dac_read,file_dac_search,sys_resource
Essentially, this means that even if the UID of the BIND service is still 0 ('root'), it will not start with all of root's privileges. Instead, it will only be granted the proc_fork, proc_exec, net_privaddr, file_dac_read, file_dac_search, and sys_resource privileges. proc_fork and proc_exec come from the basic privilege listed above. Certainly, this is already a significant reduction in the privilege set granted to the BIND service. Further, during the testing for this article, a simple configuration was created that only used proc_fork and net_privaddr. As a rule, you may be able to further reduce the default set of privileges depending on your configuration and requirements. To see more detailed information about the privileges, see privileges(5). To change the UID used to start the BIND service, use the svccfg(1M) command to configure the service as follows (assuming the named account and group have been created in a manner similar to that described above). Note that these steps only change the UID used by the process and does not impact the privileges that have been defined in the start/privileges property.
# svccfg -s dns/server:default setprop start/user = named # svccfg -s dns/server:default setprop start/group = named # svcadm refresh dns/server
There is one additional step that must be taken to successfully start the server. Depending on your configuration you may need to adjust some file paths or even file ownership or permissions to ensure that the named account can read or write files as appropriate (since the service is no longer starting as root at all). For example, an options flag must be added to the /etc/named.conf file to direct the pid-file parameter to a location writable by the named user or group. This is necessary since the named service is no longer starting as root and therefore will not be able to write to /var/run. Technically speaking, the pidfile is no longer used in Solaris since SMF is used to manage service administration, including restarts. For a more detailed example describing how to configure SMF services to start with reduced privileges, see the Sun BluePrint titled 'Limiting Service Privileges in the Solaris 10 Operating System', available from: http://www.sun.com/blueprints/0505/819- 2680.pdf. Once these changes have been made, the service can be started using the command:
# svcadm enable dns/server
The status of the dns/server service can be verified using the following commands:
# svcs dns/server
STATE STIME FMRI
online 18:43:01 svc:/network/dns/server:default
# pcred `pgrep named`
5842: e/r/suid=53 e/r/sgid=53
# ppriv -S `pgrep named`
5842: /usr/sbin/named
flags = <none
E: file_dac_read,file_dac_search,net_privaddr,proc_exec,proc_fork,sys_resourc
I: file_dac_read,file_dac_search,net_privaddr,proc_exec,proc_fork,sys_resourc
P: file_dac_read,file_dac_search,net_privaddr,proc_exec,proc_fork,sys_resource
L: zone

If you are interested in fine tuning which privileges you want Solaris to grant each service, more information can be found in the BluePrint titled 'Privilege Debugging in the Solaris 10 Operating System' found at http://www.sun.com/blueprints/0206/819-5507.pdf

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-6(2)

Plugin: Unix

Control ID: e2ad96e91427c4cbf2edb756b8b43075cb7c0faa226cfb77c81630e70704d2de