On Mon, Jan 16, 2017 at 03:37:11PM +1100, Damian McGuckin wrote: > On Mon, 16 Jan 2017, Stuart Henderson wrote: > > [...] > > > > Prior to the change to make -p an error, but after the dns pledge was > > added, -p was allowed but ignored with a warning. See the commit adding > > SOCK_DNS. > > 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. > > > Maybe I need more enlightening on my poor understanding of pledge as to > > > why restricting the port number to only 53 is needed. > > > > Some people just use dig for looking up DNS records and I think for them > > the dns pledge restrictions are a useful way to limit bug damage. > > Pledge is great. But I cannot see the link between pledge and killing off > the '-p' option. Maybe I am getting senile, or just too much summer sun on > my brain. When a program is using the "dns" promise, the kernel could enforce several restriction that are network related. Basically with "stdio rpath dns", the program could: - doing stdio stuff - accessing readonly any file - having a limited access to network, just for doing DNS stuff The point of using "dns" instead of "inet" promise is on "limited access to network" and "for doing DNS stuff". The implementation of "for doing DNS stuff" relies on the socket(2) flag SOCK_DNS with permit the kernel to enforce restriction on the way the socket is used. In these restrictions, the port number is included: a socket flagged with SOCK_DNS couldn't use another port than 53. And it is the link with -p flag. 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. > [...] > > Alternatively you could use the version of dig from packages which > > doesn't use pledge: > > > > pkg_add isc-bind > > /usr/local/bin/dig -p > > > > However, because this one doesn't use pledge at all, bugs are a bigger risk. > > I thought the whole idea of using NSD/UNBOUND is to avoid installing > 'isc_bind'. sthen@, does a subpackage for tools like dig could be a way ? Eventually with pledging it with "inet" (instead of "dns") ? > I still cannot see what risk there is on qujerying a DNS on a non-standard > port. Enlighten me please? > pledge(2) isn't a magic bullet, but a mitigation. By using pledge with "dns", you ensure the program could reach network only on limited way. As dig has also "rpath", it means a bug in dig could makes the program to be able to exflitrate file contents. With "dns", the exfiltration is more complex (but not impossible I agree: pledge is only a mitigation). Thanks. -- Sebastien Marie
