chown'ing pid and socket files

Michael Tokarev mjt at tls.msk.ru
Thu Apr 28 09:03:41 UTC 2022


Hi!

What is the reason to chown the pid file and the unix-domain
socket file as done by the daemon?

I see almost no other software doing this, and I see no need
to do this in the first place.

For the pid file (for which there's already a CVE# assigned),
there's no real need to remove the pid from there on exit.
All software which deals with daemon restarts is able to
check if the given pid corresponds to the process in question
(we know its name).  So if we'll have stale pid file which
will point to some other random process in the system, nothing
wrong will happen.

On the other way, and this is, I think, more important, having
a pid file owned by an unprivileged user creates a possibility
for interesting attacks in case our unprivileged user will be
compromised (and this is why we use unprivileged user to begin
with - to minimize the risk in case it is compromised).  Many
sysv-init shell scripts do not check for possible hostile content
of the pid files, this is a common practice to expect only a
single number in these files. And when you write a startup
script for unbound, you usually follow the same practice,
without realizing this one needs to be dealt with much more
carefully.

The thing is that once unbound is compromised, it is possible
to write anything to its pid file. Including some fun stuff
which will make a startup script (which is run as root) to
behave in some interesting way.

In other words, in my opinion it is much more important to
keep system security in a good shape than to clean a stale
pid file which is not a problem at all.

I'd remove the code which changes ownership of the pid file
completely, there's no reason for it to exist in the first
place.

Something similar is about the control socket too. For one,
there's no need to chown it to the unbound user, - let's
keep it root-owned. There IS a reason to chgrp it however,
to restrict its access to the group which is perfectly
fine. There isn't much a compromised user can do here with
a socket owned by them, but there's no *need* to grant them
ownership of this socket either.

How about the attached patch?

Thanks,

/mjt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unbound-nochown.diff
Type: text/x-patch
Size: 2031 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20220428/41253baa/attachment.bin>


More information about the Unbound-users mailing list