Bug 454415 - dnsmasq --user=nobody broken on F9
dnsmasq --user=nobody broken on F9
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnsmasq (Show other bugs)
9
All Linux
high Severity high
: ---
: ---
Assigned To: Jima
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-08 07:52 EDT by Tomas Hoger
Modified: 2009-06-10 02:36 EDT (History)
4 users (show)

See Also:
Fixed In Version: dnsmasq-2.45-1.fc9
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 02:36:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-07-08 07:52:16 EDT
Description of problem:
In F-8, dnsmasq is run under user nobody, group dip.  In F-9, this changed to
root:dip, however, this change does not seem to be documented in the RPM changelog.

Please consider running dnsmasq as non-privileged user, dedicated user is
commonly preferred for network-facing services.  Also group used by dnsmasq -
dip - seems to be a dial-up group.  According to some source, dnsmasq may be
using this group by default to get access to /etc/ppp/resolv.conf , though I'm
not sure if this is needed for Fedora.

If the change to running as root was intentional, it would be nice to have it
briefly documented in the changelog.

Version-Release number of selected component (if applicable):
dnsmasq-2.40-1.fc8.x86_64
dnsmasq-2.41-0.8.fc9.x86_64

Steps to Reproduce:
ps -ef | grep dnsmasq
cat /proc/`/sbin/pidof -x dnsmasq`/status
Comment 1 Daniel Berrange 2009-01-23 08:10:24 EST
I've just figured out why the use of  dnsmasq --user=nobody argument has no effect in Fedora 9 - no matter what arg you give it, it always runs as root. Indeed it should be dropping privileges to nobody by default, no args required.

I rebuilt the original 2.41-0.8.fc9 SRPM and the new build worked correctly, dropping privileges, so there was some problem with the original build.

Stracing my new binary and comparing to an strace of the original binary, showed the problem

- capset(0x20071026, 0, {CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW}) = -1 EPERM (Operation not permitted)
- time(NULL)                        = 1232712885
+ capset(0x19980330, 0, {CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW}) = 0
+ prctl(0x8, 0x1, 0x6182, 0xb09fc0, 0x11) = 0
+ setuid32(99)                      = 0
+ capset(0x19980330, 0, {CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0
+ time(NULL)                        = 1232712809


So, with the original binary, the capset() call fails with EPERM. When this happens, dnsmasq is unable to drop privileges, since it needs various capabilities in order to work.

Notice, that the first argument to capset() is different for the old binary (0x20071026) vs the new binary (0x19980330).

That value 0x20071026, corresponds to the Linux _LINUX_CAPABILITY_VERSION_2 constant in /usr/include/linux/capability.h, while 0x19980330 corresponds to  _LINUX_CAPABILITY_VERSION_1.

Eventually I discovered that the kernel-headers package that the original Fedora 9 build was done against, has a broken #define for the capability version, causing builds to default to the broken  _LINUX_CAPABILITY_VERSION_2 version. 


The kernel source has this to say about v2

/*
 * Version 2 capabilities worked fine, but the linux/capability.h file
 * that accompanied their introduction encouraged their use without
 * the necessary user-space source code changes. As such, we have
 * created a version 3 with equivalent functionality to version 2, but
 * with a header change to protect legacy source code from using
 * version 2 when it wanted to use version 1. If your system has code
 * that trips the following warning, it is using version 2 specific
 * capabilities and may be doing so insecurely.
 *
 * The remedy is to either upgrade your version of libcap (to 2.10+,
 * if the application is linked against it), or recompile your
 * application with modern kernel headers and this warning will go
 * away.
 */


Thus we really do need a new build of dnsmasq in Fedora 9. It should be dropping privilegs by default, and only fails todo so because it was built against broken kernel headers. This is a potential security problem.

I notice there *is* actually a new build of dnsmasq 2.45 avialable in koji for Fedora 9, but this has never been pushed out as an update for unknown reasons ?!?!
Comment 2 Daniel Berrange 2009-01-23 08:12:11 EST
FYI, I changed the version to F9, since F10/rawhide have a newer builds which correctly drop privs, since they weren't built against broken kernel headers.
Comment 3 Tomas Hoger 2009-01-29 08:09:59 EST
I've submitted existing 2.45-1.fc9 as an update.  It's what is already in F10, and not affected by this bug.  Daniel, nice work nailing this down!
Comment 4 Fedora Update System 2009-01-29 18:00:32 EST
dnsmasq-2.45-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update dnsmasq'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1069
Comment 5 Bug Zapper 2009-06-09 21:58:51 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Tomas Hoger 2009-06-10 02:36:22 EDT
Should have been closed by bodhi before:
  https://admin.fedoraproject.org/updates/F9/FEDORA-2009-1069

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