Design proposal for a better ACL language

[Mark Atwood]

I like the idea of a better defined ACL language

Are there other good ACL languages that we can steal the spec or
implementation from
How hard will it be to implement this and make sure that implementation is
not itself an attack surface
It is important that the language be readable and writable by GUIs and by
audit tools

..m


On Fri, Jun 10, 2016 at 12:02 PM Daniel Franke <dfoxfranke at gmail.com> wrote:

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