/var/run/directory/
Colin Walters
walters at redhat.com
Sun Oct 3 15:08:05 UTC 2004
On Sat, 2004-10-02 at 04:50 -0700, Steve G wrote:
> >Currently in the strict policy every daemon is permitted to create files
> >under /var/run.
>
> Can they not be limited to 1 well known file in selinux?
No; the kernel doesn't have any idea of particular file names. You can
however in SELinux specify a specific type to be used for a new inode
created in a particular directory (currently it inherits the same type).
But simply creating a directory for each daemon which is labeled by RPM
installation should work.
> >The problem is that a daemon which runs as root can (if
> >compromised) create /var/run files with the names used by other daemons if
> >the daemon is not running at the time. This interferes with stopping and
> >starting daemons.
>
> There are only 3 daemons that I can think of that need to be root: sshd, xinetd,
> crond. That's because they start programs targeted for various accts. Almost all
> other daemons should drop root pretty quick. Without being root, they cannot
> overwrite pid files.
It can be a very significant amount of work to change a daemon to run as
non-root, like dhcpcd. Also you can't fix third-party apps. And you
still reduce the problem to just a few instead of solving it.
> >For daemons that run as non-root this also makes things easier for non-SE
> >systems as there is no need to create a pidfile such as /var/run/sm-client.pid
> >and chown it,
>
> I don't buy this. The code is already there. Are you thinking to rewrite how
> every daemon records its pid?
Most of them should hopefully be configurable.
> >Can anyone think of a reason not to do this?
>
> Well, you will need to maintain a bunch of patches.
Our initscripts already represent a delta from upstream, this wouldn't
be that large relative to the current delta.
> I just question the scope of the problem - meaning how many daemons fall into
> this category of retaining root.
There's still the general problem with discretionary access control here
too - A simple misconfiguration in for one of the daemons before it
drops root privileges could cause it to overwrite the pid file for
another daemon, violating the system security policy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041003/d35e5a13/attachment.sig>
More information about the fedora-devel-list
mailing list