Re: Chronyd NTS under Ubuntu 24 - group permissions
Christian Ehrhardt <[email protected]> Tue, 16 Sep 2025 08:27:08 +0200
| Newsgroups | gmane.comp.time.chrony.user |
|---|---|
| Message-ID | <CAATJJ0JtTX8cB+PfXYx7y9RXwJO5EHYosrfoVeYogXKcNqzcMw@mail.gmail.com> |
On Tue, Sep 16, 2025 at 2:03=E2=80=AFAM Mikhail <mikhail-rh3qjuY/[email protected]> wro= te: > > 1) NTS keys are generated by letsencrypt/certbot and in Ubuntu are access= ible to group ssl-certs. > I can add Chrony user _chrony to group ssl-certs, and verify that user ca= n access the certificates. > Also, I added AppArmor exception to allow Chorny to access the keys. > Still Chrony won't be able to access the keys as Chrony seems to be strip= ping group permission from itself. > > What is the valid path to making NTS work without actually copying/chown-= ing keys on schedule? Hi Mikhail, per [1] the usual path is in /etc/chrony/*.pem which AFAIK (and hope) is also matching the usual path upstream would expect and is what you'll see in examples. That path is already open for read-only in the apparmor rules. At least our own automation [2][3] will automatically pass the private keys and store them in a compatible way - so location/permissions was never a problem I was presented with internally before. [1]: https://documentation.ubuntu.com/server/how-to/networking/serve-ntp-wi= th-chrony/#nts-server [2]: https://github.com/canonical/chrony-operator/blob/main/lib/charms/tls_= certificates_interface/v3/tls_certificates.py [3]: https://discourse.charmhub.io/t/the-tls-certificate-interface-document= ation/11635 > I would prefer to keep private keys in single place. If that is your goal then I'd expect exactly what you did or considered alr= eady: - you'd point the chrony config to that new place and adapt the apparmor rules to allow chrony to read from there - to not chown the files you'd need to change the other side - the user user chrony runs with (`user` directive in chrony.conf). But both changes appear as potential security risks to me. Keeping the private keys together means once that path is exposed all of them might be exposed. Same for the permissions, I actually like that e.g. chrony can only access its own files and only those that an extra step of chown made clear it is meant to read. I'm not at all challenging what and why you do - after all there is always one more way to set up a system. But it seems like - for the comfort of having all private keys in one place - it could weaken some of the standard defenses, which explains why it isn't easy (and probably should not be). ... [snip] ... --=20 Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd -- To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "unsubscribe" in the subject. For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the subject. Trouble? Email [email protected]