Re: [chrony-users] Chrony as non-root user (again)

[Kevin <kevincox@xxxxxxxxxxx>]

On 9/14/20 6:03 AM, Miroslav Lichvar wrote:
> On Thu, Sep 10, 2020 at 07:28:23PM -0400, Kevin wrote:
> > I know it has been discussed a number of times before on this list (ex:
> > https://www.mail-archive.com/chrony-users@xxxxxxxxxxxxxxxxxxxx/msg01751.html)
> > however it seems like it was dismissed too quickly.
> Maybe this mail has more details:
> https://www.mail-archive.com/chrony-dev@xxxxxxxxxxxxxxxxxxxx/msg01731.html

I have read that discussion but don't see what points you are referring to.

> > However it seems to me that all of these (except maybe for HW timestamping,
> > I am not familiar) can be managed by more fine grained permissions such as
> > chaining the group or ACL of the device node, creating the directories
> > beforehand or via process capabilities.
> There are devices that chronyd may need to open in some configurations
> and there are also capabilities that chronyd may need. Without parsing
> the configuration file we don't know in advance. I don't think
> requiring the admin to modify those permissions and capabilities per
> configuration would be acceptable. Setting the permissions for all
> devices that chronyd might ever need and allowing all the capabilities
> would weaken the security.
This is what I mean. As the admin I know what devices I will need for 
the selected chrony features and I can provide access to just those devices.
> > Would it be possible to enable running chrony as a non-privileged user?
> Removing that check is easy. My concern is that it would lead to some
> distributions switching their default service, which would either
> break some features or give the chrony user too many privileges that
> it doesn't usually need to have.

I see your concern. However as the admin in this case it does limit what 
I have available in order to force distribution maintainers to behave. I 
think that at the end of the day it is probably best to leave this to 
package maintainers and admins to decide what is best for their users.

As for breaking features I don't think this will be a major concern as 
the failure will be obvious. As I understand it after reading the config 
chrony opens all of the files it needs (before dropping privledges) so 
it would be easy to produce an obvious error "Can not access $thing, 
your admin or package maintainer has made a mistake, do not report this 
issue to chrony developers."

Of course it isn't easy to detect the case where more than what is 
required has been opened up. However possibly with suitable 
documentation this is not a major issue?

> On systems where configuration is fixed, or can be modified only in a
> small extent (e.g. change NTP servers), this would make more sense,
> but I think the developers can patch that out if needed.
>
> What do you suggest?
I am definitely capable of patching the code if this is the recommended 
course of action. However as a minimum it would be nice to have 
something more endorsed and less brittle. Even putting the code behind a 
build option would be nice. That way the patches (or sed commands) don't 
stop working if it is reformatted slightly.

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.