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.
Attachment:
signature.asc
Description: This is a digitally signed message part
