Re: Unprivileged user can kill root-owned processes by changing PID file and stopping service

[Frank Thommen <systemd-devel@xxxxxxxxxxxxxxxx>]

> Lennart Poettering <lennart@xxxxxxxxxxxxxx> hat am 19.02.2021 15:44 geschrieben:
> 
>  
> On Fr, 19.02.21 15:12, Frank Thommen (systemd-devel@xxxxxxxxxxxxxxxx) wrote:
> 
> > Dear all,
> >
> > I am experiencing the issue, that an unprivileged user can kill
> > root-owned processes by changing a service's PIDFile.
> 
> The file referenced by PIDFile= should not be under control of an
> unpriv user.
> 
> v219 is more than 5 years old. Since then we have tightened controls:

I am aware of this, but unfortunately for the time being we are stuck with this version (CentOS 7.4).


> we now automatically detect wether the PID file is under control of
> unprivileged users either directly, or because a symlink is used in
> the path that is controlled by an unprivileged user, in which case
> we'll log abou this. We'll also ignore the PID file if the listed PID
> doesn't actually belong to the cgroup of the service.
> 
> See documentation about PIDFile= in current versions:
> 
> https://www.freedesktop.org/software/systemd/man/systemd.service.html#PIDFile=
> 
> But in general: don't do this! It's simply not safe, neither on
> systemd nor any other init system. The whole PID concept of UNIX is
> racy anyway but giving unprivileged users control on it is even worse.
> 
> PID files are mostly SysV construct. A better replacement is using
> Type=notify or Type=simple services that do not fork unnecessarily,
> and thus do not need to communicate their main PID explicitly.

I understand that, but whatever is required for the "notify" service type is probably not a core competence of those who wrote the current service :-). I have therefore created a special service account which shares the group with the developers' account, so that it can read all required data but the developers cannot modify any of the service's files like the PIDFile and the start script.  That works quite fine and we can probably use this setup as a template for future "mini services"

Cheers and thanks for your feedback,
Frank, Heidelberg


> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel