/var/run/directory/

Steve G linux_4ever at yahoo.com
Sun Oct 3 17:37:47 UTC 2004


>> Can they not be limited to 1 well known file in selinux?
>
>No; the kernel doesn't have any idea of particular file names.  

OK...I guess that answers it.

>But simply creating a directory for each daemon which is labeled by RPM
>installation should work.

OK, this sounds like just changing where a daemon writes the pid file instead of
re-writing the code so fchown isn't called. Good.

>> There are only 3 daemons that I can think of that need to be root: 
>>sshd, xinetd, crond. 
>
>It can be a very significant amount of work to change a daemon to run as
>non-root, like dhcpcd.  

Right. However, I think in the long term, you want to get as many converted as
possible. That adds 1 more layer of protection just in case someone figures out a
hole in se linux. That's one reason why I was asking if someone's tried to
determine the scale of the problem. Besides programs that spawn others under
various accts, they can usually be converted given time.

>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.

I haven't seen this, you'd have to code an exploit just for it. But what I do see
is daemons that crash leaving a pid file. Sooner or later a pid will match what's
in the pid file and can be killed by mistake. (root is usually the only one that
can do this.) I don't think this was mentioned so far in this thread. But this is
the real problem that people run across more often wrt pid files, not overwriting
a neighboring one.

I'm not against the proposal. I think it helps. I just want to try to air some of
the details so more people understand what's be proposed.

-Steve Grubb


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail




More information about the fedora-devel-list mailing list