/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