<div dir="ltr">I like the idea of a better defined ACL language<div><br></div><div>Are there other good ACL languages that we can steal the spec or implementation from</div><div>How hard will it be to implement this and make sure that implementation is not itself an attack surface</div><div>It is important that the language be readable and writable by GUIs and by audit tools</div><div><br></div><div>..m</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 12:02 PM Daniel Franke <<a href="mailto:dfoxfranke@gmail.com">dfoxfranke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Remove the following existing configuration commands:<br>
<br>
* discard<br>
* restrict<br>
* controlkey<br>
* requestkey<br>
* trustedkey<br>
<br>
And replace them with a directive named 'rule', with the following<br>
EBNF syntax:<br>
<br>
rule = 'rule', {predicate}, disposition, [key]<br>
predicate = ['not'], atom<br>
atom = 'source', CIDR-BLOCK<br>
| 'destination' CIDR-BLOCK<br>
| 'srcport', range<br>
| 'dstport', range<br>
| 'type', type<br>
| 'mode', mode<br>
| 'version', range<br>
| 'assoc', assocstatus<br>
| 'hiskey', range<br>
| 'hiskey match'<br>
| 'authentic', boolean<br>
| 'avgrate', INTEGER<br>
| 'minrate', INTEGER<br>
| 'flake', [INTEGER]<br>
range = INTEGER, ['-', INTEGER]<br>
type = 'request' | 'response' | 'cryptonak' | 'kod', [STRING]<br>
mode = 'clientserver' | 'symmetric' | 'broadcast' | 'query' | 'modify'<br>
assocstatus = 'permanent' | 'ephemeral' | 'none'<br>
boolean = 'true' | 'false' | 'yes' | 'no'<br>
disposition = 'allow' | 'peer'<br>
| 'drop' | 'ignore' | 'unpeer'<br>
| 'kod', [STRING]<br>
| 'cryptonak'<br>
key = 'mykey', INTEGER<br>
<br>
Additionally, add the 'enablemodify' directive which takes no<br>
arguments.<br>
<br>
Each time a packet arrives, it is first checked agaist one implicit<br>
rule (given below), unless the 'enablemodify' has directive is given<br>
Then it is checked against each 'rule' directive in the configuration<br>
file, in order. If all the predicates in a rule directive match, the<br>
packet is processed according to the specified disposition, and the<br>
outgoing response (if any), is MACed using the specified key. If one<br>
or more predicates do not match, the next rule is checked. If no rule<br>
matches, the packet is then checked against some built-in implicit<br>
rules (given below), which finally end with a catch-all 'rule deny'<br>
directive. The user may effectively disable these implicit rules by<br>
including a catch-all rule of his own so that they are never reached.<br>
<br>
The predicates have the following meanings:<br>
<br>
source CIDR-BLOCK: the request was sent from an IP in the given CIDR<br>
block, which may be given as IPv4, IPv6, or v4-mapped IPv6.<br>
<br>
destination CIDR-BLOCK: ditto but for the destination to which the<br>
packet was sent (only interesting if ntpd is listening on multiple<br>
ports)<br>
<br>
srcport/dstport: the request was sent from or to the given port or<br>
range of ports.<br>
<br>
type: Whether the packet is a request, a (normal) response, a<br>
crypto-NAK, or a KoD. Broadcast packets are considered responses.<br>
Symmetric-mode packets that do not correspond to any existing<br>
association are considered requests. Symmetric-mode packets that do<br>
correspond to an existing association match both 'type request' and<br>
'type response'. If the optional string argument is given for a kod,<br>
it matches only KoDs with the given string in the refid field.<br>
<br>
mode: Match on the mode of the packet<br>
clientserver: any mode 3 or mode 4 packet<br>
symmetric: any mode 1 or mode 2 packet<br>
broadcast: any mode 5 packet<br>
query: any mode 6 packet<br>
modify: a mode 6 packet which will modify the configuration if processed<br>
<br>
version: Match on the packet's version number<br>
<br>
assoc: Match on the status of ntpd's association with the sender:<br>
permanent, ephemeral, or none.<br>
<br>
hiskey: Match on the packet's keyid field. In the "hiskey match" form,<br>
this implies "type response", and the keyid must match the one that<br>
was used for the corresponding request.<br>
<br>
authentic: Match on whether a MAC is present and valid<br>
<br>
avgrate: Matches if the sender has been sending packets at an average<br>
rate greater than or equal to 2^n seconds.<br>
<br>
minrate: Matches if it has been less than 2^n seconds since we last<br>
received a packet from this sender.<br>
<br>
flake: Matches if a random number between 1 and 100 is greater than or<br>
equal to the argument. If omitted, the argument defaults to 10.<br>
<br>
The dispositions have the following meanings:<br>
<br>
allow: Process the packet; do not change association status with the<br>
sender<br>
<br>
peer: Process the packet; additionally, if the packet is<br>
symmetric-active or broadcast, set up an ephemeral association with<br>
the sender if no association currently exists.<br>
<br>
deny: Take no action on the packet besides updating the MRU cache for<br>
rate control<br>
<br>
ignore: Take no action on the packet whatsoever<br>
<br>
unpeer: Do not reply to the packet, and delete any association with<br>
the sender<br>
<br>
kod: Reply to the packet with a KoD with the given refid field. If not<br>
specified, defaults to "RATE".<br>
<br>
cryptonak: Reply to the packet with a crypto-NAK.<br>
<br>
Basic sanity checks, such as validating the origin timestamp, are<br>
always performed, prior to applying any 'rule' directives. No rule<br>
directive will ever cause such packets to be accepted.<br>
If a 'mykey' clause is given, it specifies the keyid used to MAC the<br>
response. If not given, and the keyid in the request is recognized,<br>
this same key will be used for the response. If the keyid is not<br>
recognized, the response will not be MACed.<br>
<br>
These are the implicit rules:<br>
<br>
rule type response mode clientserver not assoc none allow<br>
rule type response mode symmetric not assoc none allow<br>
rule type kod mode clientserver not assoc none allow<br>
rule type kod mode symmetric not assoc none allow<br>
rule type request mode clientserver allow<br>
rule source <a href="http://127.0.0.0/8" rel="noreferrer" target="_blank">127.0.0.0/8</a> mode query allow<br>
rule source [::1/128] mode query allow<br>
rule deny<br>
<br>
These rules mean: accept responses (including unauthenticated ones)<br>
and honor KoDs from servers and symmetric peers with which we have an<br>
existing association; serve responses to basic time requests from<br>
clients; answer ntpq queries from localhost; and deny everything else.<br>
<br>
Additionally, the following implicit rule is processed *prior* to the<br>
rules in configuration file unless the 'enablemodify' directive is<br>
given:<br>
<br>
rule mode modify deny<br>
<br>
Note that giving 'enablemodify' is not by itself sufficient to allow<br>
any modification requests to be processed, since these would fall<br>
through to the 'rule deny' catch-all unless the user gives a rule<br>
specifying that some should be accepted. enablemodify exists only as<br>
an extra safeguard to protect the user from writing overbroad rules<br>
which accept such requests by accident.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div>