Bug 699713 - dhcpd running as root
Summary: dhcpd running as root
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 16
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 693381
TreeView+ depends on / blocked
Reported: 2011-04-26 12:49 UTC by Jiri Popelka
Modified: 2011-09-12 15:10 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2011-09-09 17:00:59 UTC

Attachments (Terms of Use)
SETroubleshoot output (2.22 KB, text/plain)
2011-07-04 10:27 UTC, Jiri Popelka
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 308832 None None None Never

Description Jiri Popelka 2011-04-26 12:49:40 UTC
+++ 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:


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?


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

Comment 1 Marko Myllynen 2011-05-19 17:01:57 UTC
CC'ing Dan in case that modifying dhcpd to use capabilities instead of running as root would require policy tweaking.

Comment 2 Daniel Walsh 2011-05-23 15:30:16 UTC
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.

Comment 3 Jiri Popelka 2011-07-01 14:49:53 UTC
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

Comment 4 Jiri Popelka 2011-07-04 10:27:26 UTC
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).

Comment 5 udo 2011-07-22 14:54:33 UTC
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.

Comment 6 Daniel Walsh 2011-07-22 20:29:36 UTC
Miroslav add policy to allow dhcpd to drop capabilities.

Comment 7 udo 2011-07-23 08:46:22 UTC
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) {
 		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?

Comment 8 Daniel Walsh 2011-07-25 15:53:24 UTC
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.

Comment 9 Jiri Popelka 2011-08-25 14:43:53 UTC
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'

Comment 10 Fedora Update System 2011-08-25 14:55:48 UTC
dhcp-4.2.2-3.fc16 has been submitted as an update for Fedora 16.

Comment 11 Steve Grubb 2011-08-25 14:57:43 UTC
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.

Comment 12 Jiri Popelka 2011-08-25 15:23:12 UTC
"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 ?

Comment 13 Steve Grubb 2011-08-25 15:37:45 UTC
It would be desirable to grab a statically allocated uid so that all installations have the same uid.

Comment 14 Jiri Popelka 2011-08-25 16:31:56 UTC
Steve: thanks
Ondra Vasik: can I get one statically allocated uid/gid for dhcpd ?

Comment 15 Ondrej Vasik 2011-08-25 19:41:08 UTC
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 ?

Comment 16 Jiri Popelka 2011-08-26 07:18:59 UTC
(In reply to comment #15)
> user dhcpd, group dhcpd, shell /sbin/nologin and created by dhcp package - ok? 

> What should be the home directory ?

Comment 17 Ondrej Vasik 2011-08-26 10:48:37 UTC
dhcpd  177:177  homedir: /var/lib/dhcpd   shell: /sbin/nologin package: dhcp

Comment 18 Ondrej Vasik 2011-08-26 10:48:56 UTC
(in Rawhide)

Comment 19 Jiri Popelka 2011-08-26 12:13:59 UTC
mitr pointed me to
so the %pre scriptlet now looks (rawhide) like

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
    groupadd -r dhcpd 
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
      useradd -r -g dhcpd -d /var/lib/dhcpd -s /sbin/nologin -c "DHCP server" dhcpd

Comment 20 Miloslav Trmač 2011-08-26 12:22:02 UTC
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.

Comment 21 Steve Grubb 2011-08-26 12:24:49 UTC
In response to comment #15, the home dir should be / for a daemon.

Comment 22 Steve Grubb 2011-08-26 12:26:02 UTC
In response to comment #20, couldn't that be made into a macro so its easier for everyone to use?

Comment 23 Miloslav Trmač 2011-08-26 12:27:37 UTC
... 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.

Comment 24 Fedora Update System 2011-08-26 14:20:29 UTC
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:
then log in and leave karma (feedback).

Comment 25 Fedora Update System 2011-09-09 17:00:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.