Wildcard-socket simplification hits a wall

[Mark Atwood]

I would like some discussion about this, however, my inclination is to drop
it.

It is my belief that when a sysadmin is going to do sophisticated filtering
based on MAC or by interface id, they will do it in their switch or they
will do locally with the ipfw or iptables feature, and would not trust the
daemon process they are trying to protect to get it right.    Every
Linux-like and modern POSIX-like OS has a kernel level table filter feature
like iptables or ipfw, and doing such filtering there is the Right Place to
do it.

I specifically would like GEM and Hal to chime on this.  Am I correct?

..m

On Thu, Mar 30, 2017 at 9:06 AM Eric S. Raymond <esr at thyrsus.com> wrote:

> Head up, Mark!  Policy issue.
>
> I fear the wildcard-socket simplification, last of our pre-1.0 major
> ambitions, has just hit a wall.
>
> The problem is not with the code simplification itself.  The problem is
> that there is a configuration feature called "NIC rules" that depends
> on knowing what actual physical interface a packet arrived on. NIC
> rules are address filters applied to individual interfaces.
>
> In order to implement this against a packet flow that is all being
> accepted by the wildcard interface, we need a way to back out of each
> packet which physical interface it arrived on.
>
> One might expect this to be available via a CMSG lookup into recmvsg's
> per-package auxiliary headers, analogously to the way we now get the
> packet-arrival timestamp (see ntpd/ntp_packetstamp.c).  It's the only
> place for the information to be that has the right locality.
>
> That's our wall.  There appears to be such auxiliary header part under
> Linux. It's not easy to say definitively, because the documentation
> of this part of the socket API is scanty and confusing.  But it looks
> like, other than the values of certain options set by sockopt(2),
> arrival time is the *only* out-of-band data you can reliably back out
> of a packet.
>
> Thus we can proceed with the simplification only at the cost of
> dropping the NIC-rule feature.  As much as I would love to drop the
> snarl of code around interface scanning, I feel I must recommend
> against this.  It would be the first case in which we take away an
> administrator tool without a specific security rationale. I fear it
> would not go over well.
>
> My recommendation is that we ship with this code undisturbed, mark
> the NIC-rule feature "deprecated" and speak of it being removed in
> the future, then see if anybody squawks.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> Of all tyrannies, a tyranny exercised for the good of its victims may
> be the most oppressive. It may be better to live under robber barons
> than under omnipotent moral busybodies. The robber baron's cruelty may
> sometimes sleep, his cupidity may at some point be satiated; but those
> who torment us for our own good will torment us without end, for they
> do so with the approval of their consciences.
>         -- C. S. Lewis
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 SMS & Signal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170331/5ddfcdd7/attachment.html>