Re: shutdown(2)'ing a bound UDP socket

[Roy Marples <roy%marples.name@localhost>]

On 20/07/2020 19:56, Peter J. Philipp wrote:
> It is unorthodox but made some sense in that I had hoped for an opportunity
> to write from a "global tuple" from other processes than the one that receives.
> Other choices I considered were writing to a raw socket but it would be a lot
> of overhead and hard work when it comes to fragmentation.  Lastly I found that
> I can set up a shared memory to write the packet back to the process that
> received it, it's entirely possibly to do so at overhead of writing the code.
> This last choice is what I'll have to do if NetBSD can't help me.
>
> And then why, you probably mean, am I spreading this functionality across
> processes.  It had to do with OpenBSD and their sandbox'ing mechanism called
> pledge(2).  The benefit of writing packets via imsg(3) and shared memory into
> a process that is "stdio sendfd recvfd" pledged in order to parse a DNS
> message is very attractive.

dhcpcd recently gained both pledge and capsicum support.
I faced a similar issue and elected to read from the bound socket in an unpriv 
chrooted process but write via a raw socket from a privileged process.
I can shutdown SHUT_RD the raw socket as it's never read from and this works 
wonderfully on all OS.

Interestingly, the raw socket approach actually removed a lot more code than it 
added because I no longer needed to play "guess the source address" in a 
specific way of using dhcpcd. This was also required to finish the capsicum 
support on FreeBSD - like OpenBSD's pledge.

> If someone managed to overflow a buffer, somehow they'd be trapped to a very
> restricted sandbox.  They can't open a file descriptor or open a network socket,
> the kernel would kill the process if they tried.  I use and develop this
> daemon of mine on OpenBSD but I want to also make it available to other
> OS's with the sandbox mechanism disabled.  It's a trade-off for those people
> that absolutely want to use delphinusdnsd but don't have OpenBSD available.

Aside from plege and capsicum, there is also the resource limited sandbox which 
works well on NetBSD and DragonFlyBSD - but ironically not at all on OpenBSD due 
to a limitation with their ppoll(2) interface.

Roy