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

[Eric S. Raymond]

Mark Atwood, Project Manager <mark.atwood at ntpsec.org>:
> 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.

That's a good explanation.  I'm keeping a copy.

(Gradually, gradually, I remedy my ignorance of infosec.)

I could summarize it something like this:

"We have removed packet filtering by interface name because we judge it's
a security-defect attractor.  The place to do this is in kernel-level packet
filters and firewalls, which get much more scrutiny; good admin practice 
in this century is to not trust usespace packet filtering at all."

This opens a can of worms, though.  Should we drop the entire interface command?

[[interface]]
+interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ | +wildcard+ | 'name' | 'address'[/'prefixlen']]::
  This command controls which network addresses +ntpd+ opens, and
  whether input is dropped without processing. The first parameter
  determines the action for addresses which match the second parameter.
  That parameter specifies a class of addresses, or a specific interface
  name, or an address. In the address case, _prefixlen_ determines how
  many bits must match for this rule to apply. +ignore+ prevents opening
  matching addresses, +drop+ causes +ntpd+ to open the address and drop
  all received packets without examination. Multiple +interface+
  commands can be used. The last rule which matches a particular address
  determines the action for it. +interface+ commands are disabled if any
  of the +-I+, +--interface+,+-L+, or +--novirtualips+ command-line options
  are used. If none of those options are used and no +interface+ actions
  are specified in the configuration file, all available network
  addresses are opened. The +nic+ command is an alias for +interface+.

I'm inclined to think dropping this would be a good thing.  There's a
lot of code complexity behind that, and that bit abour interface
commands being inoperative if you choose the wrong command-line option
raises my shoot-self-in-foot alarm.

I'd like to hear from our security officer about this.  I'd also lilke
to hear from people with lots of ops experience like Hal and Matt.
-- 
		<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.