On Mon, 16 Jan 2017, Sebastien Marie wrote:
On my OpenBSD 5.1 system, '-p' was still allowed, and it had a pledge list
of "stdio dns". When 'rpath' was added to the pledge list, it was at this
time at which '-p' was effectively disabled.
The implementation of "dns" promise has been refined with the time.
Got it. I am enlightened.
In these restrictions, the port number is included: a socket flagged
with SOCK_DNS couldn't use another port than 53.
OK. That explains a lot.
And it is the link with -p flag.
OK. That explains everything.
Note that in socket(2), it says
SOCK_DNS
For domains AF_INET or AF_INET6, only allow connect(2),
sendto(2), or sendmsg(2) to the DNS port (typically 53).
Those words are a lot looser than your words which are
a socket flagged with SOCK_DNS couldn't use another port than 53.
It would appear there is nothing typical about 53. It is either 53 or it
is nothing. In the light of the your comments, the last few words should
say something to the effect
to the DNS port (only 53 allowed)
Looking in the code within 'asr_run(3)' shows that 53 is hard-coded.
For looking up DNS records, "dns" is the right promise to use.
Others use dig as a DNS server debugging tool and I think in those cases
the port restriction (and forcing traffic through rebound if it's running)
can get in the way.
I agree with sthen@. For debugging purpose, things are more complex, and
"dns" doesn't fit well.
I am not convinced that the ISC's move to 'dig' from nslookup and the even
simpler utility 'host' was done as cleanly and securely and as flexibly as
it could have. But I did not contribute so who am I to complain.
sthen@, does a subpackage for tools like dig could be a way ? Eventually
with pledging it with "inet" (instead of "dns") ?
One of the strengths of Unix is that its user tools can act as diagnostic
tools. Trying to limit that flexibility is counterproductive at times. And
balancing that with security is a difficult task and I am not sure I have
the answer. However, having 2 versions of 'dig' is not a solution. And as
I /usr/local/WHATEVER first, the 'pledged' dig would be lost.
All I know is that having a working utility with 'dig -pPORT#' saved me an
inordinate amount of time in identifing my own particular esoteric problem
over the last weekend. It has put me in a position where I can complain
(loudly) to the ISP knowing the problem is theirs! Now my only issue is
identifying where in the router chain is there the rule while blocks port
53 getting through to the OpenBSD box. It seems like the ISP hierarchy
cannot find the problem. I wonder if there is something like 'traceroute'
for DNS requests.
Looking at the whole functionality of host/nslookup/dig, along with, or in
the context of the asr_run(3), might be a useful exercise. But what do I
know, except maybe a little bit more than I did before I read your reply
Sebastien!
Many thanks for taking the time to explain the issues. Tout est clair!
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
