[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: /var/run/directory/



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]