Design proposal for a better ACL language

[Eric S. Raymond]

Daniel Franke <dfoxfranke at gmail.com>:
> On 6/13/16, Mark Atwood <fallenpegasus at gmail.com> wrote:
> 
> > Are there other good ACL languages that we can steal the spec or
> > implementation from
> 
> Most of the features we want to match on (basically everything except
> IP/port) are NTP-specific, so not directly. But a lot of my design was
> inspired by iptables.

Mark, none of my concerns about this proposal are design level; Daniel
did a good job there. The iptables minilanguage is a good model and a
tasteful, well-considered choice.

> > How hard will it be to implement this
> 
> Eric's first impression was that it would be hard to integrate this
> into NTP's existing data structures. We of course need to create
> completely new data structures to represent the ACL rules, but we
> hardly have to touch the existing ones. The stuff related to restrict
> and discard directives can be removed. I designed the predicates
> related to rate control and to ephemeral vs. permanent associations to
> be compatible with NTP's existing concepts, so those bits don't have
> to change.

Daniel, I think you are understimating some friction costs here -
potentially quite seriously.

The implementation of this must have three parts: (1) Yacc/Lex tweaks to do the
parsing, (2) new intermediate data structures to hold the iptables-like
rule information, (3) transcoding the table info to existing ntpd structures.

I'm not worried about part 1; I can do that kind of grammar-hacking in
my sleep.

I'm only a little concerned about part 2; it's a fairly simple matter
of programming. The risks are significant but pretty much all around
the kind of resource-management screwup that causes simple crashes and
static analyzers are good at heading off. And I'm pretty good at avoiding
this class of errors, anyway.

I'm significantly concerned about part 3.  In any transition like
this, there is a *lot* of potential for subtle bugs due to ontological
mismatches between the new and old ways of doing things.  It's going
to be a defect attractor, potentially a very nasty one with security
impact (as in, what if a buggy rules transcode fails open?) and unlike
part 2 it's not one where we get a lot of insulation from the
implementor being a code-slinging wizard.

I'm enough concerned that I must recommend against attempting this revamp
until we've solved the TESTFRAME problem, entirely because of part 3.

It could have been othwerwise.  Daniel might have come up with a
sufficiently simple set of changes that I would be OK with mentally
proving their conditional correctness to myself.  He didn't.
Consequences follow.

I also think Daniel is understimating the degree of pushback this
might get from our userbase and potential users.  It is a much more
radical change than the excisions and renames we've done so far, and
there's going to be (justified) concern about transition and defect
risks.

All of which says to me that Daniel's proposal, or something like it,
is probably a good idea but not for the near future.  We've got some
street cred now, but we'd be pushing it pretty hard if we tried this.
More trust-building is called for first, IMO.

> > and make sure that implementation is not itself an attack surface
> 
> The gist of my plan is to push as much complexity as possible toward
> startup time, before any adversarial input is ever processed,
> compiling everything down into a simple table. Then every incoming
> packet follows pretty much the same code path, branching only once at
> the very end once its disposition has been decided. We'll then still
> need lots of unit tests to catch configuration parsing bugs, but with
> design those bugs are unlikely to become vulnerabilities.

Mark, independently of my misgivings above I strongly, *strongly*
endorse the intent of this 'graph. That is sound thinking and I believe
it can deliver the minimal exposure Daniel promises.

> > It is important that the language be readable and writable by GUIs and by
> > audit tools
> 
> This is nice-to-have, but I think a more important consideration is
> misuse-resistance. Users *will* screw up; let's make it hard to hurt
> themselves when they do so. That's why I added all the implicit rules
> and the 'enablemodify' directive, so that the defaults are so safe and
> so are most non-defaults that you're likely to write by accident.

I think I'm somewhere between the two of you on this one.  I agree with
Daniel that not-shoot-self-in-foot is more omportant, but I would reserve the
option of tweaking the grammar towards Mark's concerns (which I agree with)
as I implemented.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>