I've cloned this issue into a new bug.

On 11/26/19 12:44 PM, Stephan Seitz wrote:
> On Mo, Nov 18, 2019 at 09:05:35 -0600, Richard Laager wrote:
> Ah, concerning the apparmor policy: I had to do a manual overwrite for
> ntp.keys (default only in /etc):
> /etc/ntpsec/ntp.keys r,

You make a good point that this should be in /etc/ntpsec. I'll look into
making that happen.

Use of ntp.keys is a scenario that doesn't get discussed much.
README.Debian says:
    ntpkeygen can be used to generate an MD5 ntp.keys file in /etc.  Use
    of these keys has not yet been tested; please report success or
    failure in using them to the maintainer." I believe that text, or at
    least the spirit, is inherited from the ntp package, and both
    upstreams are curious to hear from users of this too.

Are you using this between your own server and clients, or between your
server and external servers? Do you anticipate NTS replacing your use of
ntp.keys? (If not, why?)

> And since you’ll probably need an entry for NTS key and certificate,
> this should maybe be mentioned in ntp.conf.

Agreed! ntp.conf has an example of the bits that belong there. The
apparmor bit is covered in README.Debian:

    When configuring ntpd as an NTS server, if your certificate and key
    files are not already covered by
    /etc/apparmor.d/abstractions/ssl_certs and ssl_keys, you will need
    to add rules to /etc/apparmor.d/local/usr.sbin.ntpd to allow reading
    them.

If you have suggested changes to that, please let me know.

The first goal is for this to work out of the box, so I have used the
existing Apparmor abstractions, which cover certbot, etc.

-- 
Richard

Reply via email to