+++ This bug was initially created as a clone of Bug #693381 +++ Description of problem: On RHEL/Fedora dhcpd seems to be running as root although on some other widely used distributions it is running as a non-root user which is very favourable from the security point of view. Please consider running dhcpd as non-root. --- Additional comment from Jiri on 2011-04-05 16:43:41 CEST --- AFAICT dhcpd needs to be run as superuser because of using of SOCK_RAW sockets. When you try to run dhcpd as non-root you get: 'unable to create icmp socket: Operation not permitted' Can you be more specific in what distributions do you have in mind ? I have tried debian stable with exactly the same results as on RHEL/Fedora, i.e. you need to be root to start the dhcp server service (called isc-dhcp-server) or directly dhcpd there. --- Additional comment from Marko on 2011-04-05 17:37:29 CEST --- > Can you be more specific in what distributions do you have in mind ? On Ubuntu dhcpd is running as user dhcpd. Interestingly, on Debian dhcpd indeed runs as root. This is definitely in the nice-to-have category but Ubuntu has a patch to use capabilities in order to be able to drop root privileges, see: http://packages.ubuntu.com/natty/isc-dhcp-server http://archive.ubuntu.com/ubuntu/pool/main/i/isc-dhcp/isc-dhcp_4.1.1-P1-15ubuntu6.diff.gz I'm CC'ing sgrubb how can possibly comment whether it would make sense for us too to use capabilities to drop root privileges with dhcpd? Thanks. --- Additional comment from Marko on 2011-04-26 10:34:24 CEST --- Jiri, do you think it would be better to open a Fedora BZ about this and if that gets implemented then continue on a RHEL BZ?
CC'ing Dan in case that modifying dhcpd to use capabilities instead of running as root would require policy tweaking.
Yes it should be running as non root, if possible and should drop capabilities after it opesn a raw socket. On Fedora it should probably use file capabilities. After you change the code, we can easily add the appropriate SELinux controls.
I have hardened dhcpd/dhcrelay by patching them to use libcap-ng[1] to drop capabilities. The capabilities dropping is done in two steps. First all capabilities except CAP_NET_RAW and CAP_NET_BIND_SERVICE[2] are dropped as soon as possible. After both daemons do the initialization and before they start to receive and dispatch packets *all* capabilities are dropped. I've done some testing and see no problems with functionality of the daemons. However I added a '-nc' option, which avoids dropping of the capabilities. It can be used to debugging problems and can be removed after some time. How to test: netcap and pscap (libcap-ng-utils package) programs shouldn't show the running daemon in the report (meaning that it has dropped all capabilities). [1] http://people.redhat.com/sgrubb/libcap-ng [2] man capabilities
Created attachment 511163 [details] SETroubleshoot output (In reply to comment #3) > I've done some testing and see no problems with functionality of the daemons. That's only true when I run dhcpd manually (dhcpd -d -cf /etc/dhcpd/dhcpd.conf). When I run it as a service I get some warnings that SELinux is preventing dhcpd from using the getcap/setcap access on a process (see attached SETroubleshoot output).
Before trying 4.2.2, running chrooted a build built with -D_GNU_SOURCE -DEARLY_CHROOT -DPARANOIA as user dhcp worked well. So whether SElinux is involved or not, it is a bug. I don't use SElinux but I lost functionality.
Miroslav add policy to allow dhcpd to drop capabilities.
In server.c we can change stuff: --- a/server/dhcpd.c 2011-07-23 10:44:55.857788129 +0200 +++ b/server/dhcpd.c 2011-07-23 10:44:40.357827722 +0200 @@ -473,7 +473,7 @@ if (!keep_capabilities) { capng_clear(CAPNG_SELECT_BOTH); capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, - CAP_NET_RAW, CAP_NET_BIND_SERVICE, -1); + CAP_NET_RAW, CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT, CAP_SETGID, CAP_SETUID, -1); capng_apply(CAPNG_SELECT_BOTH); log_info ("Dropped all unnecessary capabilities."); } Then a build with -DEARLY_CHROOT -DPARANOIA works when started as e.g.: ./dhcpd -user dhcp -group dhcp -chroot /chroot/dhcpd eth0 No errors about missing capabilities. But perhaps these extra capabilities can be dropped after using them?
I think you will need the following in policy. allow dhcpd_t self:capability { chroot net_raw setgid setuid sys_resource } And I would check the running dhcpd with pscap to see if it has any capabilities. It should drop them all.
Since upstream version of dhcp-4.1.0 a "paranoia" patch has been included, but it's not compiled in by default. It implements three options: -user, -group and -chroot. Since dhcp-4.2.2-2.fc16 we: - build with "paranoia" enabled - create/delete system user dhcpd in %%post, %%postun - run dhcpd/dhcpd6 services with '-user dhcpd -group dhcpd'
dhcp-4.2.2-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/dhcp-4.2.2-3.fc16
Quick question, did you reserve a system uid or does it take an unreserved system uid? (We just bumped up the uids from 500 to 1000 to allow more reserved uids.) If so, the setup package needs updating too.
"unreserved system uid" ? I was thinking that new system user always gets one of the reserved uids. In spec file I create the user with 'useradd --system dhcpd' so it takes 996 uid on my freshly installed F16. Do I need to do anything else ?
http://fedoraproject.org/wiki/Features/1000SystemAccounts#Detailed_Description It would be desirable to grab a statically allocated uid so that all installations have the same uid.
Steve: thanks Ondra Vasik: can I get one statically allocated uid/gid for dhcpd ?
Well, new bugzilla against rawhide setup would be better for tracking - but ok, we could handle it here ... so it will be user dhcpd, group dhcpd, shell /sbin/nologin and created by dhcp package - ok? What should be the homedirectory ?
(In reply to comment #15) > user dhcpd, group dhcpd, shell /sbin/nologin and created by dhcp package - ok? right > What should be the home directory ? /var/lib/dhcpd
Reserved: dhcpd 177:177 homedir: /var/lib/dhcpd shell: /sbin/nologin package: dhcp
(in Rawhide)
mitr pointed me to https://fedoraproject.org/wiki/Packaging:UsersAndGroups so the %pre scriptlet now looks (rawhide) like %pre getent group dhcpd >/dev/null || groupadd -r -g 177 dhcpd getent passwd dhcpd >/dev/null || \ useradd -r -u 177 -g dhcpd -d /var/lib/dhcpd -s /sbin/nologin -c "DHCP server" dhcpd But the packaging policy doesn't talk about whether/how to test for allocation of UID/GID, i.e. what if the 177 UID/GID is already taken by some other user/group ? Do we care ? What about something like this ? getent group dhcpd >/dev/null if [ $? -ne 0 ]; then getent group 177 >/dev/null if [ $? -ne 0 ]; then groupadd -r -g 177 dhcpd else groupadd -r dhcpd fi fi getent passwd dhcpd >/dev/null if [ $? -ne 0 ]; then getent passwd 177 >/dev/null if [ $? -ne 0 ]; then useradd -r -u 177 -g dhcpd -d /var/lib/dhcpd -s /sbin/nologin -c "DHCP server" dhcpd else useradd -r -g dhcpd -d /var/lib/dhcpd -s /sbin/nologin -c "DHCP server" dhcpd fi fi
That's what I'd suggest, except perhaps that > if ! getent passwd dhcpd > /dev/null ; then and so on would be a bit more idiomatic.
In response to comment #15, the home dir should be / for a daemon.
In response to comment #20, couldn't that be made into a macro so its easier for everyone to use?
... and yes, it is quite possible for the value 177 to be already taken on systems that have been continually upgraded from older Fedora versions, or on systems that use a centralized UID assignment. (In reply to comment #22) > In response to comment #20, couldn't that be made into a macro so its easier > for everyone to use? Well, first the FPC needs to agree to the principle of this as the recommended policy; then we can discuss adding a macro.
Package dhcp-4.2.2-4.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dhcp-4.2.2-4.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/dhcp-4.2.2-4.fc16 then log in and leave karma (feedback).
dhcp-4.2.2-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.