1:05 p.m.
I have been thinking about the /var/run directory under SE Linux.
Currently in the strict policy every daemon is permitted to create files
under /var/run. 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.
The solution to this is to have a directory under /var/run for each daemon and
give write access to that directory only to the daemon that uses 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, the directory can just have the permissions needed to allow file
creation by the daemon.
Can anyone think of a reason not to do this? Or should I just start filing
bugzilla entries against all packages that have /var/run/daemon.pid files?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
1:45 p.m.
Russell Coker (russell(a)coker.com.au) said:
Currently in the strict policy every daemon is permitted to create
files
under /var/run. 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.
The solution to this is to have a directory under /var/run for each daemon and
give write access to that directory only to the daemon that uses 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, the directory can just have the permissions needed to allow file
creation by the daemon.
Can anyone think of a reason not to do this? Or should I just start filing
bugzilla entries against all packages that have /var/run/daemon.pid files?
Well, it will break parts of the initscripts if it's just done
in the daemons. :)
Bill
7:46 p.m.
On Sat, 2 Oct 2004 04:45, Bill Nottingham <notting(a)redhat.com> wrote:
> Can anyone think of a reason not to do this? Or should I just
start
> filing bugzilla entries against all packages that have
> /var/run/daemon.pid files?
Well, it will break parts of the initscripts if it's just done
in the daemons. :)
Naturally changes to the daemon, the init scripts for the daemon, and to the
SE Linux policy need to be synchronised. But apart from that do you have any
problem with the idea?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:18 p.m.
Russell Coker (russell(a)coker.com.au) said:
> Well, it will break parts of the initscripts if it's just
done
> in the daemons. :)
Naturally changes to the daemon, the init scripts for the daemon, and to the
SE Linux policy need to be synchronised. But apart from that do you have any
problem with the idea?
You need to change the generic initscripts as well... they rely
on the pid file location.
Bill
11:32 p.m.
Bill Nottingham (notting(a)redhat.com) said:
Russell Coker (russell(a)coker.com.au) said:
> > Well, it will break parts of the initscripts if it's just done
> > in the daemons. :)
>
> Naturally changes to the daemon, the init scripts for the daemon, and to the
> SE Linux policy need to be synchronised. But apart from that do you have any
> problem with the idea?
You need to change the generic initscripts as well... they rely
on the pid file location.
Moreover, you break the FHS (and therefore, LSB.)
Bill
2:30 a.m.
On Sat, 2 Oct 2004 14:32, Bill Nottingham <notting(a)redhat.com> wrote:
Bill Nottingham (notting(a)redhat.com) said:
> Russell Coker (russell(a)coker.com.au) said:
> > > Well, it will break parts of the initscripts if it's just done
> > > in the daemons. :)
> >
> > Naturally changes to the daemon, the init scripts for the daemon, and
> > to the SE Linux policy need to be synchronised. But apart from that do
> > you have any problem with the idea?
>
> You need to change the generic initscripts as well... they rely
> on the pid file location.
Moreover, you break the FHS (and therefore, LSB.)
Below is the relevant section of the FHS. It says that programs which use
more than one file are encouraged to use a sub-directory (IE Sendmail).
Doing the same for programs which only have a single file is not a major
break.
/var/run : Run-time variable data
Purpose
This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process. Programs may have a subdirectory of /var/run; this is
encouraged for programs that use more than one run-time file. [42]
Process identifier (PID) files, which were originally placed in /etc,
must be placed in /var/run. The naming convention for PID files is
<program-name>.pid. For example, the crond PID file is named
/var/run/crond.pid.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:09 a.m.
Russell Coker (russell(a)coker.com.au) said:
Below is the relevant section of the FHS. It says that programs
which use
more than one file are encouraged to use a sub-directory (IE Sendmail).
Doing the same for programs which only have a single file is not a major
break.
It says that pid files *must* be placed in /var/run, and that
subdirectories can be used for other process data, as I'm reading
it.
Bill
6:50 a.m.
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?
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.
The only daemons that you have to worry about are the ones that stay as root. How
many stay as root?
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? Or just to change the name of the pid file? These
are 2 entirely different scopes of a fix.
Can anyone think of a reason not to do this?
Well, you will need to maintain a bunch of patches. The daemon, spec file (to
create the /var/run/daemon dir), and initscripts will need adjusting. The end
user wouldn't really notice it since this magic occurs under the hood.
I just question the scope of the problem - meaning how many daemons fall into
this category of retaining root. And why can't selinux limit a daemon to 1 file
in the /var/run directory. That file should be well known.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
10:08 a.m.
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.
12:37 p.m.
> 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
1:51 p.m.
On Sun, 2004-10-03 at 10:37 -0700, Steve G wrote:
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.
Right.
>> 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.
True. But you have to weigh the effort involved in that versus other
security threats, and I don't think in a lot of these cases it's worth
it.
>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.
I'm not talking about an exploit; a system administrator could
accidentally overwrite e.g. the <pidfile> section
of /etc/dbus/system.conf when pasting in configuration from elsewhere.
SELinux will prevent the configuration error from damaging the rest of
the system.
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.
Makes sense.
4:24 p.m.
a system administrator could accidentally overwrite e.g. the
<pidfile>
section of /etc/dbus/system.conf when pasting in configuration from elsewhere.
I see what you're talking about. Why is that configurable? All other daemons I've
audited have it hardcoded either in config.h, a header, or right in the .c files.
find /usr/sbin/ -name '*' -exec strings {} \; | grep \/var\/run
In addition to selinux enhancement, I'd take the pid file configuration out of
the dbus.conf file. That flexibility just isn't needed and as mentioned, might
actually be a security risk.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
8:11 p.m.
On Sun, 2004-10-03 at 14:24 -0700, Steve G wrote:
>a system administrator could accidentally overwrite e.g. the
<pidfile>
>section of /etc/dbus/system.conf when pasting in configuration from elsewhere.
I see what you're talking about. Why is that configurable? All other daemons
I've
audited have it hardcoded either in config.h, a header, or right in the .c files.
find /usr/sbin/ -name '*' -exec strings {} \; | grep \/var\/run
In addition to selinux enhancement, I'd take the pid file configuration out of
the dbus.conf file. That flexibility just isn't needed and as mentioned, might
actually be a security risk.
It's configurable because the same executable is the system daemon and
the session daemon, they differ by config file. The session daemon has
no pidfile.
The filename could be in config.h though, just not the flag for whether
to write it out.
Havoc
1:03 a.m.
On Mon, 4 Oct 2004 03:37, Steve G <linux_4ever(a)yahoo.com> wrote:
>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
I believe that the vast majority of exploits are created just for one
particular bug.
Also there have been bugs related to problems in dropping privs, see the
following URL for one example:
http://www.ale.org/archive/ale/ale-2000-06/msg00065.html
I recall that in late 2002 there was a game which had a security hole whereby
corrupt game data could exploit a program that was started at boot as root,
unfortunately I can't find the details.
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.
The solution to this is to check the executable name as well as the PID before
killing. For SE Linux we will probably eventually want to go further and
either check the process context or run the kill command in the same domain
as the daemon.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:50 p.m.
Colin Walters (walters(a)redhat.com) said:
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.
While creating a new problem for finding pid files... do you go
by the service name? The server name? Something else?
Bill
12:15 a.m.
On Mon, 4 Oct 2004 13:50, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)redhat.com) said:
> 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.
While creating a new problem for finding pid files... do you go
by the service name? The server name? Something else?
How would the problem be any greater than it is right now? In terms of what
name to use (service, server, or something else) it's exactly the same issue
as we have at the moment with /var/run/something.pid.
I bet that almost no-one can name both pid files for Sendmail from memory. If
they were in /var/run/sendmail there would be no doubt.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
12:22 a.m.
Russell Coker wrote:
I bet that almost no-one can name both pid files for Sendmail from memory. If
they were in /var/run/sendmail there would be no doubt.
Maybe this is a dumb question, but what's the point of pid files,
anyway? Are they used by anything other than the init.d scripts?
Why not just use /sbin/pidof instead?
--
Jamie Zawinski
jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
3:01 a.m.
On Sun, Oct 03, 2004 at 10:22:17PM -0700, Jamie Zawinski wrote:
Maybe this is a dumb question, but what's the point of pid
files,
anyway? Are they used by anything other than the init.d scripts?
Why not just use /sbin/pidof instead?
pidof matches strings in /proc/*/cmdline. The match may be imperfect
and could catch other processes (think user-created processes whose
argv[0] names are set to match a system daemon).
pidof may also return pids of child processes of the daemon. This can
be a problem if you are trying to restart a daemon such as sshd--you
don't want to kill all open ssh connections, just restart the parent
daemon.
Using a pid file that was created by the parent daemon itself prevents
these problems, as long as you can trust who has access to write the
pid file.
9:23 a.m.
Once upon a time, Jamie Zawinski <jwz(a)jwz.org> said:
Maybe this is a dumb question, but what's the point of pid
files,
anyway? Are they used by anything other than the init.d scripts?
Why not just use /sbin/pidof instead?
Maybe because it cannot work right?
In a multi-user system, there is nothing that prevents a user from
creating something that calls itself "sshd", "sendmail",
"xinetd", etc.
that pidof will see. Also, if you want to restart a service that forks
children (like sshd and sendmail), you generally don't want to kill all
the children as well. The only way to know which process is the master
is to look for a PID file.
I opened a Bugzilla requesting enhancement to the init.d functions a
couple of years ago because of this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63440
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:02 p.m.
On Tue, 5 Oct 2004 00:23, Chris Adams <cmadams(a)hiwaay.net> wrote:
I opened a Bugzilla requesting enhancement to the init.d functions a
couple of years ago because of this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63440
When sending a signal to a daemon to be sure that we get things right we need
to check:
PID number in pidfile (which needs to be in a subdirectory for a non-root
process to be able to restart itself).
Executable that is being run. If the daemon crashes and another process gets
the same pid then we don't want to kill the wrong thing, checking that the
program matches the daemon is a good way to do it. The start-stop-daemon
program used in Debian does this. One issue with such checks is that you
must stop the daemon before upgrading it, otherwise an attempt to stop it
will fail because the executable for the daemon no longer exists.
For SE Linux we also want to check the security context. It's not difficult
to ask the kernel what happens when the domain specified
in /etc/selinux/strict/contexts/initrc_context executes the type of the
executable for the daemon and then check that the process to be killed is
running in the domain in question.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:45 a.m.
Russell Coker (russell(a)coker.com.au) said:
> While creating a new problem for finding pid files... do you go
> by the service name? The server name? Something else?
How would the problem be any greater than it is right now?
Right now it's basename of the process.
In terms of what
name to use (service, server, or something else) it's exactly the same issue
as we have at the moment with /var/run/something.pid.
If you move to this new thing, do you do one dir per daemon? One
per process? Something else?
Bill
9:54 p.m.
On Mon, 4 Oct 2004 23:45, Bill Nottingham <notting(a)redhat.com> wrote:
Russell Coker (russell(a)coker.com.au) said:
> > While creating a new problem for finding pid files... do you go
> > by the service name? The server name? Something else?
>
> How would the problem be any greater than it is right now?
Right now it's basename of the process.
Except in the case of /var/run/sm-client.pid which has a process base-name of
"sendmail". I'm sure that there are other similar exceptions too.
> In terms of what
> name to use (service, server, or something else) it's exactly the same
> issue as we have at the moment with /var/run/something.pid.
If you move to this new thing, do you do one dir per daemon? One
per process? Something else?
One per security context. So have /var/run/sendmail for sendmail.pid and
sm-client.pid as they are both part of the sendmail service.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:19 p.m.
Russell Coker (russell(a)coker.com.au) said:
On Mon, 4 Oct 2004 23:45, Bill Nottingham <notting(a)redhat.com>
wrote:
> Russell Coker (russell(a)coker.com.au) said:
> > > While creating a new problem for finding pid files... do you go
> > > by the service name? The server name? Something else?
> >
> > How would the problem be any greater than it is right now?
>
> Right now it's basename of the process.
Except in the case of /var/run/sm-client.pid which has a process base-name of
"sendmail". I'm sure that there are other similar exceptions too.
There are overrides to the daemon function that makes some of this
work, but it doesn't work *well*.
> If you move to this new thing, do you do one dir per daemon?
One
> per process? Something else?
One per security context. So have /var/run/sendmail for sendmail.pid and
sm-client.pid as they are both part of the sendmail service.
Then there's really no good way for Joe Random Process to know
that the pid for sm-client is in the sendmail dir.
Bill
11:29 p.m.
On Thu, 7 Oct 2004 13:19, Bill Nottingham <notting(a)redhat.com> wrote:
> > If you move to this new thing, do you do one dir per
daemon? One
> > per process? Something else?
>
> One per security context. So have /var/run/sendmail for sendmail.pid and
> sm-client.pid as they are both part of the sendmail service.
Then there's really no good way for Joe Random Process to know
that the pid for sm-client is in the sendmail dir.
There's absolutely no way for Joe Random Process to know that the pid for the
second copy of /usr/sbin/sendmail.sendmail is named sm-client.pid! If
sm-client.pid was in the directory /var/run/sendmail then figuring out that
the sendmail process is related to the /var/run/sendmail directory is not
overly difficult.
I am not suggesting that we do anything new, I am merely suggesting that the
practices of putting pid files in sub-directories as currently used by
Quagga, mdadm, radiusd (*), and dovecot be extended for more daemons. I
think that your point about the difficulty for Joe Random Process in finding
the pid file is a really good one and supports my case well.
(*) The radiusd start script creates a sym-link /var/run/radiusd.pid which
points to the real location. This is a good idea, I would be happy
if /var/run was filled with sym-links and directories containing the real
files.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7157
days inactive
7163
days old
23 comments
8 participants
participants (8)
-
Bill Nottingham -
Chris Adams -
Chuck Anderson -
Colin Walters -
Havoc Pennington -
Jamie Zawinski -
Russell Coker -
Steve G