Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

2019-01-20 Thread Simon Kelley
It's a known limitation. The  actual limitation is that a CNAME and it's
target must both either originate from an upstream server, or both
originate from the dnsmasq local configuration. Mixing sources (ie CNAME
from upstream and target from dnsmasq, or vice-versa) is not allowed.

The commonest situation, when a CNAME is defined in dnsmasq's
configuration whose target comes from upstream, is noted a a problem in
the man page, but that doesn't mention what you're doing, defining the
CNAME upstream but the target in dnsmasq. It should probably do that.

Workaround is to add the CNAME to the dnsmasq configuration.

Cheers,

Simon.




On 20/01/2019 11:03, Yossi Boaron wrote:
> 
> Hi All,
> I have the following DNS topology (In my Openstack deployment):
> VM --> DNSMASQ --> external DNS server 
> domain name= shiftstack.com , and Dnsmasq 2.76
> is used at this Openstack deployment.
> 
> I run the following test:
> 1. Define CNAME record at external DNS server
> 
> ostest-etcd-5.shiftstack.com .   
>  IN   CNAME        ostest-master-2
> 
> 2. while 'ostest-master-2' is defined in --addn-hosts at Dnsmasq:
> the relevant entry:
> 10.0.1.214      ostest-master-2.shiftstack.com
> . ostest-master-2
> 
> 3. next step, I tried to resolve 'ostest-etcd-5.shiftstack.com
> .' from the VM.
> I expected that dig ostest-etcd-5.shiftstack.com
> . should be replied with the
> ostest-master-2 IP (10.0.1.214).
> 
> Actual behavior:
> When I run dig (see 1)  just for type A, Dnsmasq replied only with the
> CNAME entry and doesn't return ostest-master-2 IP address.
> 
> But when I run dig (see 2) for types  and A (at this order), I can
> see that Dnsmasq resolves  ostest-master-2 IP address as expected.
> 
> It seems to me like an issue of CNAME caching  at Dnsmasq (2.76), 
> Is it a known issue?
> 
> Thanks in advance
> Yossi
> 
> 
> [1] 
> $ dig +noedns  ostest-etcd-5.shiftstack.com
> .  A
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> +noedns ostest-etcd-5.shiftstack.com
> . A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13837
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      A
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> 
> ;; Query time: 2 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:52:48 UTC 2019
> ;; MSG SIZE  rcvd: 118
> 
> $ 
> 
> [2] 
> $ dig +noedns ostest-etcd-5.shiftstack.com
> .
>   ostest-etcd-5.shiftstack.com
> .  A
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> +noedns ostest-etcd-5.shiftstack.com
> .
>  ostest-etcd-5.shiftstack.com . A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63573
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> 
> ;; Query time: 3 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 118
> 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15671
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      A
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> ostest-master-2.shiftstack.com .
> 0 IN    A       10.0.1.214
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 106
> 
> $ 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

2019-01-20 Thread Yossi Boaron
I run the same test with Dnsmasq 2.80 (2.80-32-g28cfe36) - and got the
similiar results.

10.0.2.200 is the VM's IP address
10.46.4.43 - is the IP address of the external DNS server

The dnsmasq log as response to ' dig +noedns  ostest-etcd-5.shiftstack.com.
A'

Jan 20 12:54:37 dnsmasq[711308]: query[A] ostest-etcd-5.shiftstack.com from
10.0.2.200
Jan 20 12:54:37 dnsmasq[711308]: forwarded ostest-etcd-5.shiftstack.com to
10.46.4.43
Jan 20 12:54:37 dnsmasq[711308]: reply ostest-etcd-5.shiftstack.com is

Jan 20 12:54:37 dnsmasq[711308]: reply ostest-master-2.shiftstack.com is
NODATA-IPv4

The dnsmasq log as response to ' dig +noedns ostest-etcd-5.shiftstack.com.
  ostest-etcd-5.shiftstack.com.  A'

Jan 20 13:07:33 dnsmasq[711308]: query[] ostest-etcd-5.shiftstack.com
from 10.0.2.200
Jan 20 13:07:33 dnsmasq[711308]: forwarded ostest-etcd-5.shiftstack.com to
10.46.4.43
Jan 20 13:07:33 dnsmasq[711308]: reply ostest-etcd-5.shiftstack.com is

Jan 20 13:07:33 dnsmasq[711308]: reply ostest-master-2.shiftstack.com is
NODATA-IPv6
Jan 20 13:07:33 dnsmasq[711308]: query[A] ostest-etcd-5.shiftstack.com from
10.0.2.200
Jan 20 13:07:33 dnsmasq[711308]: cached ostest-etcd-5.shiftstack.com is

Jan 20 13:07:33 dnsmasq[711308]:
/var/lib/neutron/dhcp/1555837d-1114-41af-9820-a4c420f6a1ae/addn_hosts
ostest-master-2.shiftstack.com is 10.0.1.214


After I run once the dig , seems that dig A command works as expected
(probably because CNAME was chached):

Jan 20 13:43:23 dnsmasq[837744]: 2655 10.0.2.200/59700 query[A]
ostest-etcd-5.shiftstack.com from 10.0.2.200
Jan 20 13:43:23 dnsmasq[837744]: 2655 10.0.2.200/59700 cached
ostest-etcd-5.shiftstack.com is 
Jan 20 13:43:23 dnsmasq[837744]: 2655 10.0.2.200/59700
/var/lib/neutron/dhcp/1555837d-1114-41af-9820-a4c420f6a1ae/addn_hosts
ostest-master-2.shiftstack.com is 10.0.1.214

Any help will be appreciated
Yossi


‫בתאריך יום א׳, 20 בינו׳ 2019 ב-13:03 מאת ‪Yossi Boaron‬‏ <‪
yossi.boaron.1...@gmail.com‬‏>:‬

>
> Hi All,
> I have the following DNS topology (In my Openstack deployment):
> VM --> DNSMASQ --> external DNS server
> domain name= shiftstack.com, and Dnsmasq 2.76 is used at this Openstack
> deployment.
>
> I run the following test:
> 1. Define CNAME record at external DNS server
>
> ostest-etcd-5.shiftstack.com. IN   CNAMEostest-master-2
>
> 2. while 'ostest-master-2' is defined in --addn-hosts at Dnsmasq:
> the relevant entry:
> 10.0.1.214  ostest-master-2.shiftstack.com. ostest-master-2
>
> 3. next step, I tried to resolve 'ostest-etcd-5.shiftstack.com.' from the
> VM.
> I expected that dig ostest-etcd-5.shiftstack.com. should be replied with
> the ostest-master-2 IP (10.0.1.214).
>
> Actual behavior:
> When I run dig (see 1)  just for type A, Dnsmasq replied only with the
> CNAME entry and doesn't return ostest-master-2 IP address.
>
> But when I run dig (see 2) for types  and A (at this order), I can see
> that Dnsmasq resolves  ostest-master-2 IP address as expected.
>
> It seems to me like an issue of CNAME caching  at Dnsmasq (2.76),
> Is it a known issue?
>
> Thanks in advance
> Yossi
>
>
> [1]
> $ dig +noedns  ostest-etcd-5.shiftstack.com.  A
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +noedns
> ostest-etcd-5.shiftstack.com. A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13837
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com.  IN  A
>
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
> ostest-master-2.shiftstack.com.
>
> ;; Query time: 2 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:52:48 UTC 2019
> ;; MSG SIZE  rcvd: 118
>
> $
>
> [2]
> $ dig +noedns ostest-etcd-5.shiftstack.com. 
> ostest-etcd-5.shiftstack.com.  A
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +noedns
> ostest-etcd-5.shiftstack.com.  ostest-etcd-5.shiftstack.com. A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63573
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com.  IN  
>
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
> ostest-master-2.shiftstack.com.
>
> ;; Query time: 3 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 118
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15671
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com.  IN  A
>
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
> ostest-master-2.shiftstack.com.
> ostest-master-2.shiftstack.com. 0 INA   10.0.1.214
>
> ;; Query time: 0 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 106
>
> $
>

Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2019-01-20 Thread P, Sreelakshmi
Hi Simon,

Thanks for the reply. Attached is the pcap file that contains malformed packet. 
Extra byte is added to client MAC address to make it malformed. 

This behavior was tested using a tool called Defensics generally used to find 
security vulnerability.

Regards,
Sree

-Original Message-
From: Dnsmasq-discuss [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] 
On Behalf Of Simon Kelley
Sent: Monday, December 17, 2018 3:21 AM
To: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

I can't answer your question about if this has been fixed, as there's not 
enough information to identify the problem or trigger the bug.

Can you provide  proof-concept code, or even just packet captures of the 
malformed packets that cause problems?

I've confused by the "dhcp to be unresponsive from the switch for a small 
amount of time." observation. What's happening here? Note that dnsmasq can 
queue DHCPDISCOVER requests whilst is if doing address-in-use testing. If 
that's causing the unresponsiveness then it's expected and there are 
mitigations in place to avoid DOS. If, on the other hand, the malformed packets 
are crashing dnsmasq and some daemon-framework is restarting it, that's bad, 
and we'd like to know about it.



Cheers

Simon.



On 10/12/2018 05:59, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> Does anyone has any update on this?
> 
>  
> 
> Thanks!
> 
>  
> 
> *From:* P, Sreelakshmi
> *Sent:* Friday, December 7, 2018 4:19 PM
> *To:* 'dnsmasq-discuss@lists.thekelleys.org.uk'
> 
> *Subject:* Validation for malformed DHCP packets in dnsmasq
> 
>  
> 
> Hi,
> 
>  
> 
> We are using dnsmasq 2.78. We see that there are some security 
> vulnerability w.r.t malformed DHCP packets as explained below.
> 
>  
> 
> *_Problem 1:_*
> 
> A malformed dhcp discover packet can cause dhcp to be unresponsive 
> from the switch for a small amount of time.  If this was repeated over 
> time an attacker could make the dhcp service unresponsive DOSing the box.
> 
>  
> 
> It starts out with the malformed discover immediately followed by a 
> dhcp decline.  then the client sends another dhcp discover packet.
> The switch does not respond to this discover.
> 
> After about two seconds the client tries again and dhcp works as 
> normal.
> 
>  
> 
> *_Problem 2:_*
> 
> DHCP request with anomaly causing DOS condition
> 
>  
> 
> A Malformed DHCP request causes dhcp server to not respond for a short 
> period of time.  The request is modified by reducing the size of the 
> data in the mac address field in the dhcp request.
> 
> After the request is sent to the switch the client sends another dhcp 
> discover which is not responded to.  After about 1.5 seconds the 
> client tries again and the discover is responded to.
> 
>  
> 
> *_Problem 3:_*
> 
> DHCP discover packet with extra byte in hardware address causing DOS 
> of DHCP on switch
> 
>  
> 
> If an extra byte is added to the hardware address field in a dhcp 
> discover it will cause the DHCP service to become unresponsive for a 
> short period of time.  If repeated it could be used as a DOS attack.
> 
>  
> 
> *_Problem 4:_*
> 
> DHCPv6 solicit with anomaly in Identity association length field 
> causing DOS
> 
>  
> 
> When the integer value 65534 is placed in the Identity association 
> length field of a dhcpv6 solicit packet the switch enters a DOS state 
> for a couple seconds
> 
>  
> 
> *_Problem 5:_*
> 
> DHCPv6 solicit 2 Extra bytes trailing option status code causes DOS
> 
>  
> 
> Sending dhcpv6 solicits with extra bytes trailing the option status 
> code causes the switch dhcp server to become temporarily unresponsive.
> 
>  
> 
> In a summary, to overcome this problem, DHCP packet validation has to 
> be done. Has any fix related to any of these problems have gone in after 2.78?
> 
>  
> 
> Thanks in Advance!!
> 
>  
> 
> Regards,
> 
> Sree
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


DhcpDiscoverExtraByteInHeader.pcap
Description: DhcpDiscoverExtraByteInHeader.pcap


BUG_15134_DhcpDiscoverExtraByteInHeader.pcap
Description: BUG_15134_DhcpDiscoverExtraByteInHeader.pcap
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

2019-01-20 Thread Yossi Boaron
Hi All,
I have the following DNS topology (In my Openstack deployment):
VM --> DNSMASQ --> external DNS server
domain name= shiftstack.com, and Dnsmasq 2.76 is used at this Openstack
deployment.

I run the following test:
1. Define CNAME record at external DNS server

ostest-etcd-5.shiftstack.com. IN   CNAMEostest-master-2

2. while 'ostest-master-2' is defined in --addn-hosts at Dnsmasq:
the relevant entry:
10.0.1.214  ostest-master-2.shiftstack.com. ostest-master-2

3. next step, I tried to resolve 'ostest-etcd-5.shiftstack.com.' from the
VM.
I expected that dig ostest-etcd-5.shiftstack.com. should be replied with
the ostest-master-2 IP (10.0.1.214).

Actual behavior:
When I run dig (see 1)  just for type A, Dnsmasq replied only with the
CNAME entry and doesn't return ostest-master-2 IP address.

But when I run dig (see 2) for types  and A (at this order), I can see
that Dnsmasq resolves  ostest-master-2 IP address as expected.

It seems to me like an issue of CNAME caching  at Dnsmasq (2.76),
Is it a known issue?

Thanks in advance
Yossi


[1]
$ dig +noedns  ostest-etcd-5.shiftstack.com.  A

; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +noedns
ostest-etcd-5.shiftstack.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13837
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ostest-etcd-5.shiftstack.com.  IN  A

;; ANSWER SECTION:
ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
ostest-master-2.shiftstack.com.

;; Query time: 2 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Jan 20 09:52:48 UTC 2019
;; MSG SIZE  rcvd: 118

$

[2]
$ dig +noedns ostest-etcd-5.shiftstack.com. 
ostest-etcd-5.shiftstack.com.  A

; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +noedns
ostest-etcd-5.shiftstack.com.  ostest-etcd-5.shiftstack.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ostest-etcd-5.shiftstack.com.  IN  

;; ANSWER SECTION:
ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
ostest-master-2.shiftstack.com.

;; Query time: 3 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Jan 20 09:53:59 UTC 2019
;; MSG SIZE  rcvd: 118

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15671
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ostest-etcd-5.shiftstack.com.  IN  A

;; ANSWER SECTION:
ostest-etcd-5.shiftstack.com. 3600 IN   CNAME
ostest-master-2.shiftstack.com.
ostest-master-2.shiftstack.com. 0 INA   10.0.1.214

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Jan 20 09:53:59 UTC 2019
;; MSG SIZE  rcvd: 106

$
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Basic Static IPv6 setup

2019-01-20 Thread Jon Spriggs
Hi,

I've read through the manual page several times, and read around online a
fair amount, and I'm struggling to find an answer to this.

I am using DNSMasq for just IPv6 IP allocation. I am using the following
config:

domain-needed
bogus-priv
no-resolv
filterwin2k
expand-hosts
domain=localnet
local=/localnet/

interface=eth0
listen-address=127.0.0.1

# DHCPv6 - Hurricane Electric Resolver and Google's
dhcp-option=option6:dns-server,[2001:470:20::2],[2001:4860:4860::]

# IPv6 DHCP scope
dhcp-range=2001:470:dead:beef::, ra-stateless
enable-ra

I would like to provide a static IPv6 address, initially to just to a
single node on my network. Short of going around and putting static
addresses on by hand, is there a way to allocate addresses in advance? I
control the node fully, so if it's done by putting a specific hostname in,
or configuring something on the host (I'm using Ubuntu on there), then I
can easily do that.

Thanks for any help!
--
Jon "The Nice Guy" Spriggs
@jontheniceguy everywhere...
https://jon.sprig.gs
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Minimal capabilities for options

2019-01-20 Thread Mathieu Hofman
Running dnsmasq in docker currently requires explicitly granting the
NET_ADMIN capability for the container, or dnsmasq fails to start if
configured to drop root.

The failure is due to a capset() call that includes NET_ADMIN when dnsmasq
attempts to keep capabilities before dropping root. If the capability is
not already available, the call fails. If dnsmasq doesn't drop root, the
checks are skipped and it starts successfully without the capability, but
potentially fails later depending on the configured options.

>From what I gather, the NET_ADMIN capability is only needed to inject a
neighbor / ARP entry after receiving a DHCP request from a client so that
the response can be sent using unicast. The capability is not required if
the DHCP server is disabled or if the dhcp-broadcast option is used.

The NET_RAW capability is similarly needed to send an ICMP ping before
allocating an address for a client, but pings are not used if the DHCP
server is disabled or if the no-ping option is specified.

I would like to suggest 2 improvements to the way capabilities are handled
in dnsmasq:

1) Only try to keep capabilities which are actually needed according to the
configured options. If the DHCP server is disabled, do not keep (or request
if not available) the NET_ADMIN and NET_RAW capabilities. If the
dhcp-broadcast option is specified, do not include NET_ADMIN. If no-ping is
specified, do not include NET_RAW.
Currently the NET_BIND_SERVICE capability is kept only if DAD or dynamic
binding are required by the config. This suggestion would use similar logic
for the NET_ADMIN and NET_RAW capabilities.

2) Check that the capabilities required for the configuration are available
to the process when starting, and fail early if they are not. Currently
capabilities are not checked. It's only a side effect of the capset() call
when dropping root that dnsmasq will fail to start if a capability is
missing. If dnsmasq is configured to not drop privileges, such as starting
as a non-root user, or staying root without changing user, dnsmasq will
only fail later when attempting to use a feature requiring the capability.

Optionally, dnsmasq could try to automatically disable any configured
feature that relies on the missing capability, and probably warn such
action was taken in the logs. For the NET_RAW capability, it's probably not
possible to disable pings if the DHCP server is not authoritative as that
might be too risky. For the NET_ADMIN capability hopefully it's safe to
automatically switch to dhcp-broadcast.

For now, I'm working around the current capabilities handling by manually
dropping root and granting the required capabilities to dnsmasq before
executing it. Dnsmasq seem to run fine from what I can tell, but I've only
tested it in my environment.
My docker config for this is here:
https://gist.github.com/mhofman/cdd85a6baa4b9206830b254d0ab9bb89

To summarize the new suggested capabilities logic would be:
- Figure out the set of capabilities required for the configured options
(regardless of user config).
- Check if the process has the required capabilities. Fail if not, or
optionally gracefully degrade features and warn.
- If configured to drop root, call capset() only with required capabilities.

The current alternative is not acceptable in my opinion: keep running as
root (or worse, in debug mode).

This change would also help pi-hole which recently added code to check for
available capabilities before invoking dnsmasq. See
https://github.com/pi-hole/FTL/issues/432

A similar request was made in 2013:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q2/007188.html

Mathieu
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss