On 31/03/2022 01:00, dnsm...@riseup.net wrote:
The reason it's like this is that if dnsmasq changed to unprivileged
action would fail if the port number was less than 1024
Look at the bug report again - its port is above 1024.
Without 'query-port=' your software always open way too many ports
(above 1024), and those conections are always made by dnsmasq user.
With 'query-port' the UDP connection was made by only this port, but
those connections are NOT MADE by dnsmasq user.
How could this is NOT A BUG!?
The UID associated with a connection is not defined anywhere in the
documentation. Indeed, as a concept it's pretty weak anyway: UID don't
exist in IP headers, so I assume this is something that only applies to
locally generated packets using iptables. Dnsmasq doesn't define the
value of the UID associated with it's sockets, and it's not clear
obvious what that that UID should be if it did, since it's meaningless,
hence not a bug.
One could argue that for ports >1024, the socket opening should be
delayed to after the dnsmasq UID is changed from root to the dnsmasq
user. That would be a backwards compatible change, since no promises
have been made about the UID on socket opening. Convince me that this is
a useful change (It's non-trivial) and I'll consider it.
Using Debian's stable btw
you lose source-port randomisation,
There is a option and I am using it.
I suggest you research DNS source-port randomisation and the Kaminski
attack. Then determine if the security you're losing by disabling source
port randomisation is compensated for by your firewall rules.
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
