daemon warning

[Mark Andrews]

In message <53B2D903.4070409 at thelounge.net>, Reindl Harald writes:
>
>
> Am 01.07.2014 17:46, schrieb Matus UHLAR - fantomas:
> >> You need to start named as root for it to be able to chroot. (Unles
> s
> >> Solaris has some cunning fine-grained privilege feature I don't kno
> w
> >> about.)
> >
> > On 01.07.14 15:18, Stewart, Larry C Sr CTR DISA JITC (US) wrote:
> >> Ok so that was not a good troubleshooting technique, was trying to
> >> determine what did not have the correct permissions and thus causin
> g the
> >> warning.  I guess I will go ahead and run it the way I have been fo
> r the
> >> last 5 years, unless I find it is causing me problems.
> >
> > For now we have to trust BIND it will properly bind(), chroot() and
> drop
> > privileges...
> >
> > does anyone know if there's a way to leave these (dropping privilege
> s) to
> > other programs, so BIND and similar apps won't have to implement thi
> s on
> > their own? ... on Linux or other OSes?
> >
> > (taking care about security of a small program should be easier)
>
> in theory http://www.freedesktop.org/software/systemd/man/systemd.sock
> et.html
>
> that way systemd opens the socket before the daemon is started
> which could happen even on-demand and so the systemd-unit could
> start the service process from the begin with a low privileged
> user - *but* not sure how to deal with chroot in that context
>
> however, we restrict most services like below, giving them only
> needed capabilities and make /etc and /usr read-only which
> greatly improves security
>
> PrivateTmp=true
> TimeoutSec=25
> Restart=always
> RestartSec=1
> CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRI
> DE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK
> CAP_SYS_CHROOT
> ReadOnlyDirectories=/etc
> ReadOnlyDirectories=/usr
> InaccessibleDirectories=/boot
> InaccessibleDirectories=/home
> InaccessibleDirectories=/root

Firstly systemd is a poor match for a nameserver.  A nameserver is
not the type of service it is designed to start.

Various OS's have different ways to let a unpriviledge process open
reserved ports which is the primary reason for starting as root.
Read your OS's documentation.

For FreeBSD i have the following in /etc/sysctl.conf

security.mac.portacl.port_high=1023
net.inet.ip.portrange.reservedlow=0
net.inet.ip.portrange.reservedhigh=0
security.mac.portacl.suser_exempt=1
security.mac.portacl.rules=uid:53:tcp:53,uid:53:udp:53

and can start named chroot'd using the following if I wish

chroot -u bind -g bind /var/chroot/named /usr/sbin/named

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org