On 6/13/16, Mark Atwood <[email protected]> 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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
