Design proposal for a better ACL language

[Daniel Franke]

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.

> 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.

> 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.

> 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.