I've played with nftables and came up with situation where I couldn't allow local queries to dnsmasq to be answered, while requests to 8.8.8.8 and 8.8.4.4 went on OK. The issue was found to be at my nft:skuid usage. After server reboot, I was able to reproduce. Here are configs&logs: ---====---r #!/sbin/nft -f flush ruleset table inet blackh { chain input { type filter hook input priority 0; policy drop; iif "lo" accept ct state 0x1 drop ct state 0x2 accept jump ping jump dnsmasq jump portage jump antminer-dhcp jump rostelecom-dhcp jump tor log prefix "nft.input" drop } chain output { type filter hook output priority 0; policy drop; oif "lo" meta skuid 43 accept jump ping jump dnsmasq jump portage jump rostelecom-dhcp jump antminer-dhcp jump tor log prefix "nft.output" drop } chain ping { iif "enp6s1f1" icmp type 0 log prefix "RT-PING" iif "enp6s1f1" icmp type 0 accept oif "enp6s1f1" icmp type 8 log prefix "RT-PING" oif "enp6s1f1" icmp type 8 accept iif "enp6s1f0" icmp type 0 log prefix "PING-ANT" iif "enp6s1f0" icmp type 0 accept oif "enp6s1f0" icmp type 8 log prefix "PING-ANT" oif "enp6s1f0" icmp type 8 accept } chain dnsmasq { iif "enp6s1f1" udp sport 53 accept oif "enp6s1f1" udp dport 53 meta skuid 275 accept oif "lo" udp sport 53 log flags skuid oif "lo" udp sport 53 skuid "dnsmasq" accept oif "lo" udp dport 53 accept } chain portage { iif "enp6s1f1" meta skuid 250 accept oif "enp6s1f1" meta skuid 250 accept } chain rostelecom-dhcp { iif "enp6s1f1" udp sport 67 udp dport 68 log prefix "RT-DHCP" iif "enp6s1f1" udp sport 67 udp dport 68 accept } chain antminer-dhcp { iif "enp6s1f0" udp sport 68 udp dport 67 log prefix "DHCP-ANT" iif "enp6s1f0" udp sport 68 udp dport 67 accept oif "enp6s1f0" udp sport 67 udp dport 68 log prefix "DHCP-ANT" oif "enp6s1f0" udp sport 67 udp dport 68 accept } chain tor { iif "lo" tcp dport 9111 accept iif "lo" tcp sport 9111 accept oif "lo" tcp sport 9111 accept oif "lo" tcp dport 9111 accept meta skuid 43 oif "enp6s1f1" tcp dport 9003 ip daddr 105.108.116.155 accept meta skuid 43 oif "enp6s1f1" tcp dport 8000 ip daddr 108.56.180.213 accept meta skuid 43 oif "enp6s1f1" tcp dport 47081 ip daddr 78.47.90.114 accept meta skuid 43 oif "enp6s1f1" tcp dport 4083 ip daddr 91.107.200.52 accept } } ---====---r Jun 19 00:23:46 descend kernel: IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=42730 DF PROTO=UDP SPT=53 DPT=41500 LEN=59 UID=0 GID=0 Jun 19 00:23:46 descend kernel: nft.outputIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=79 TOS=0x00 PREC=0x00 TTL=64 ID=42730 DF PROTO=UDP SPT=53 DPT=41500 LEN=59 anek@descend ~ $
I'm not really sure what the problem is here, what in particular is the security boundary/expectation being crossed?
I haven't any issue with this, but just noticed this at the very end of the day. I thought of this as of bug in either kernel or dnsmasq. Just needed to post it somewhere, and security could very well be involved.
So the issue is that, although dnsmasq is told to drop root priveleges in config, and clearly does that, as `ps aux` shows user `dnsmasq`, it just doesn't do it really, that's strange.
I've tried to put DNSmasq at unpriveleged 5353, issue remains
I admit I'm not at all familiar with the internals of dnsmasq, but it sounds like it opens the socket as root and then drops privileges.
(In reply to John Helmert III from comment #5) > I admit I'm not at all familiar with the internals of dnsmasq, but it sounds > like it opens the socket as root and then drops privileges. Now that it's been said to you in cleartext, I do understand that kernel internals keep uid, like, for FD, and this is expected behavior. Well then, sorry for misunderstanding, I really did think that it's a bug. If this looks OK, please close the bug.
