On Mon, Jan 16, 2017 at 06:58:59AM +0100, Sebastien Marie wrote: > 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). >
Why not make pledge dns dependent the -p flag? Remi
