Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)

Tue May 29 15:44:44 UTC 2018

There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.

The UNIX concept: each tool should do one thing, and do it well.   The ntpd
should no more do packet filtering than the packet filers should implement
the NTP protocol.

Separation of knowledge.  The packet filers know how the network stack is
implemented, and how the local site has plumbed them.  Repeating this
knowledge in the ntpd violates DRY, and are hard to keep in sync.

Separation of configuration.  Network configuration tools know to speak to
the packet filter API and know to speak to the switch APIs.   Asking those
tools to speak to every random daemon's implementation of each own control
interface is asking too much.

Assumption of mistrust.  Admins and devops people now assume (after 40+
years of bitter experience) that all daemons are broken and insecure.  That
lack of trust extends to any given daemon's own (probably half assed and
poorly reviewed) implementation of packet filters.

Assumption of corruption.  Once a bad guy has presented a malicious packet
stream to a daemon, you cannot trust that daemon's own logging, or trust
any part of that daemon's execution paths. Including the execution of it's
own packet filters!

Linus's Law, and it's weaknesses.  The packet filters are the point where
Linus's Law has engaged about packet filtering.  The slightest quiver of
uncertainly in the packet filter implementations will trigger CERT
conference calls, corporate sev2 incidents, and personal line-by-line
hand-execution code audits by technical leads.   The discovery of yet
another parsing bug in a userspace daemon is called a "Tuesday".

The "half of common lisp" narrative.  Just like every large programmable
system eventually has a poorly specified implementation of parts of Lisp,
every local single process userspace implementation of packet filtering is
just a poorly specified poorly performent implementation of the the packet
filter.

..m

On Tue, May 29, 2018 at 3:13 AM Eric S. Raymond via devel <devel at ntpsec.org>
wrote:

> Mark Atwood <fallenpegasus at gmail.com>:
> > No modern sysadmin or devops shop is going to use or trust an userspace
> > packet filter built into the userspace daemon they are defending.
>
> Hm.  I am ignorant here.  Why is this so?
>
> > This is an ancient feature that is a fossil evidence that NTP was a known
> > security tarpit predating the widespread deployment of the kernel packet
> > filter or edge switch filters.
> >
> > We will drop this feature.
> >
> > We can explain why, and every netadmin and devops manager will agree with
> > the reason.
>
> I am not arguing with the decision - it is exactly yours to make - but I'd
> like
> to see an explanation in a form I can put in a doc patch.  I'll first
> cleanly
> remove it with explanation, then implement SINGLESOCK.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be
> your own.
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20180529/ed56af52/attachment.html>