Bug 1547932

Summary: libvirt starts dnsmasq which runs as nobody user
Product: [Fedora] Fedora Reporter: Zbigniew Jędrzejewski-Szmek <zbyszek>
Component: dnsmasqAssignee: Petr Menšík <pemensik>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 27CC: agedosier, berrange, clalancette, code, dougsland, dustymabe, itamar, jforbes, jima, laine, libvirt-maint, p, pemensik, thozza, veillard
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-23 02:50:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1537262, 1591969    

Description Zbigniew Jędrzejewski-Szmek 2018-02-22 10:15:01 UTC
Description of problem:
When libvirt.service is started, is starts a bunch of processes, including dnsmasq. dnsmasq has two processes: one runs as root, and one runs as nobody!
This is insecure and in direct contradiction to packaging guidelines [https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups].

Version-Release number of selected component (if applicable):
libvirt-daemon-3.7.0-3.fc27.x86_64
dnsmasq-2.78-2.fc27.x86_64

How reproducible:
This seems deterministic, at least on two machines I tested.

Comment 1 Laine Stump 2018-02-22 14:21:09 UTC
libvirt doesn't set the uid for the dnsmasq process. It execs dnsmasq and leaves it to do whatever is appropriate.

Try enabling dnsmasq.service then starting it. You'll see the same issue.

Comment 2 Zbigniew Jędrzejewski-Szmek 2018-02-22 15:19:22 UTC
Yes, it's very likely that the similar bug exists in dnsmasq.service. Note that the issue exists at the _service_ level. Each time dnsmasq is running in a separate service, it must be using a dedicated user. Thus, libvirt must take care to run dnsmasq appropriately.

Comment 3 Daniel Berrangé 2018-02-22 15:24:55 UTC
Re-assigning to dnsmasq, since libvirt isn't picking the "nobody" user account - it is a decision compiled into dnsmasq - Fedora should patch it to run as a "dnsmasq" user account by default.

Running each separate dnsmasq process in a different user account is total overkill so not something we would do in libvirt - just let dnsmasq pick a more suitable default account.

Comment 4 Zbigniew Jędrzejewski-Szmek 2018-02-22 15:36:19 UTC
In the meantime I opened a separate bug against dnsmasq.

I think "your" dnsmasq should get a dedicated user, so that it can never step on the toes of the dnsmasq from dnsmasq.service, and vice-versa. Let's see what dnsmasq maintainers say.

Comment 5 Itamar Reis Peixoto 2018-02-22 17:12:21 UTC
(In reply to Daniel Berrange from comment #3)
please take a look ->

https://bugzilla.redhat.com/show_bug.cgi?id=1548050


dnsmasq accepts the user/group parameters,

user=dnsmasq
group=dnsmasq

I think libvirt should include these info on -> 

/var/lib/libvirt/dnsmasq/default.conf

if you move default.conf to /etc/dnsmasq.d and run dnsmasq with -conf-file=/etc/dnsmasq.conf then it will run under dnsmasq.conf user (after this https://src.fedoraproject.org/rpms/dnsmasq/pull-request/1  merged)

Comment 6 Daniel Berrangé 2018-02-22 17:33:41 UTC
Yes, I know libvirt could set a custom user / group via config, but that doesn't solve the root cause problem. The Fedora guidelines linked above say:

  "Note that system services packaged for Fedora MUST NOT run as the nobody user, but MUST instead allocate their own system user. "

so that strongly says that dnsmasq's built-in default should be changed to run as dnsmasq user account. Once that's done there's nothing needed in libvirt.

Comment 7 Zbigniew Jędrzejewski-Szmek 2018-02-22 18:08:52 UTC
My point is that dnsmasq-binary-running-in-dnsmasq.service, dnsmasq-binary-running-in-libvirt.service, and any other instance, are all separate users.

The wider picture is that users are the strongest security and separation mechanism that Linux has, and we should use as many of them as possible.

Comment 8 Laine Stump 2018-02-22 19:37:39 UTC
Setting user= in the example conf file is inadequate, even for the instance of dnsmasq started by the dnsmasq service file. See my comment in the pull request for the patch that does that:

https://src.fedoraproject.org/rpms/dnsmasq/pull-request/1

The default user should be set in dnsmasq's src/config.h.

Comment 9 Itamar Reis Peixoto 2018-02-23 02:50:55 UTC
(In reply to Laine Stump from comment #8)

ok, fixed in dnsmasq side, closing this one, thank you for the suggestion.

*** This bug has been marked as a duplicate of bug 1548050 ***