| Re: [chrony-dev] [Regression 3.5 -> 4.0-pre1]: Could not remove /run/chronyd.pid : Permission denied |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] [Regression 3.5 -> 4.0-pre1]: Could not remove /run/chronyd.pid : Permission denied
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Wed, 6 May 2020 14:12:08 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588767134; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Md5AR/cs+WYK320NEEfLbj83F6m2Lg4m4UDDFYN0ITc=; b=C7JHtZLJ0vNSP82StCAl5oJik06v7Rv9E9+Wqvlk6sGz9IltgiXwHkbE93pfrP6HU9ub/a mJ7nQTHEYorILGPvoKKTGwnt2XrECPydqJxIHm7MFo1urwR1Dar3Hw5HG2AwYwPquSGp6N 4YvYTRsVWfx3wC2GcZlSB7JCA8JIJu4=
On Tue, May 05, 2020 at 09:58:54PM +0200, Vincent Blut wrote:
> Well, by bypassing discretionary access control with CAP_DAC_OVERRIDE, we
> probably give even more privileges to root until chronyd switches to the
> configured unprivileged system user while this could be avoided by setting
> the correct Unix permissions. There is a nice blog post¹ about this from an
> SELinux member.
Ok, I see how this helps with selinux. I'm not quite sure yet if it's
worth complications in the code. There are few things to consider:
- The umask of the process will need to be set to 0 or maybe 007, but
only when it has the root privileges (e.g. not when a regular user
uses the -Q option). I'm not sure if someone doesn't rely on chrony not
changing the umask.
- We'll probably want to change this for all directories created by
chrony.
- The check of /var/run/chrony that disables the cmdmon socket if
an unexpected owner/permission is found will probably need to allow
the chrony group in order to not break chronyd after upgrade (when
the old directory is not removed).
- It doesn't seem to be a common practice. On my system I don't see
any directory in /var/run, /var/lib, /var/log that would have an
$UID:root owner. Most of the non-root directories there have
$UID:$GID of the user, and some have root:$GID. Would it make sense
to consider that instead of $UID:root?
Thoughts?
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.