pid file issues
Carter Bullard
carter at qosient.com
Tue Mar 19 12:48:52 EST 2002
Hey Yotam,
Regardless of whether we're going to specify the
directory or file, I don't think I can do it in one
flag, so I'll do the -c for "do a pid file", and -n to
specify whatever we decide, a directory or a file.
I can see us doing either one, so lets go through the
situation. Currently, if you specify that you want to
create a PID file, you will get an interesting pid filename
in either /var/run or $ARGUSHOME, that includes the interface
being used and an index. The existing strategy is that
we want to limit the total number of argi (system burden),
and have a simple way to kill them when needed.
With our existing implementation, we cannot use the pid
file for exclusion to enforce that only a single argus is
running as a daemon. Being able to do exclusion is
a good thing, so I've added the "-I n" option, so you
can specify how many instances are allowable (default
will become 1).
Now with this default strategy, a common directory for
pid files with argus deciding how to name the files, we
can control the number of total system argi. If we allow
the argus to define the pid file directory or filename, we
lose this property.
If we allow argus to specify the pid file directory,
we can prevent bad pid filename choices, if we support
pid filenames, then we can't prevent anything, which is
ok at one level, and somewhat irresponsible on the other?
Suggestions?
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter at qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com]
> Sent: Tuesday, March 19, 2002 11:12 AM
> To: 'Yotam Rubin'; 'Argus'
> Subject: RE: The patch.
>
>
> Hey Yotam,
> Well, there is nothing that I can do to enforce
> that a user protect their /etc/argus.conf file.
> Giving a program the potential to create rogue pid
> files is an interesting problem, as it can setup a
> very subtle non-corrupting denial of service attack
> against other system daemons. This is much different
> from the problems that programs can cause by corrupting
> or deleting files.
>
> Since most daemons don't generate syslog output
> when there is an existing daemon, it could be
> an attack that would be quite difficult to detect.
>
> I see an advantage to specifying the directory the
> pid should be in, (avoid OS issues) and allowing
> the application to name the pid file, but I don't
> see any real advantage to a script specifying the
> actual pid filename. Now if we're having problems
> with argus's strategy of naming pid files, we should
> change that.
>
> What do you think?
>
> Carter
>
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York 10022
>
> carter at qosient.com
> Phone +1 212 588-9133
> Fax +1 212 588-9134
> http://qosient.com
>
>
> > -----Original Message-----
> > From: owner-argus-info at lists.andrew.cmu.edu
> > [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> > Yotam Rubin
> > Sent: Tuesday, March 19, 2002 10:27 AM
> > To: Argus
> > Subject: Re: The patch.
> >
> >
> > On Tue, Mar 19, 2002 at 09:48:47AM -0500, Carter Bullard wrote:
> > > Hey Yotam,
> > > Hmmmm, I think you're missing my important point,
> > > and I apologize for not being precise.
> > >
> > > If a process with root privileges is allowed to create
> > > any pid file, without restrictions, there is nothing to
> > > keep it from creating, say, /var/run/identd.pid,
> > > as an example. If this is possible, then there is the
> > > real possibility that the program can be used to prevent
> > > key programs from running. The real identd starts, finds
> > > the rogue pid file, signals the pid that is in the file
> > > and finds that there is a running process, and then
> > > exists, since pid files are used by most programs as
> > > an exclusive mechanism.
> >
> > Yes. That's exactly what I've been talking about. Like I've
> stated in
> > my private response, how is this problem limited only to the
> > creation of
> > pid files? _Any_ program that allows the user to specify a
> > file for writing
> > (e.g., log files) is prone to this problem. This problem can
> > only happen
> > if a malicious user gains access to sensitive files. If this
> > is the case,
> > then you have a bigger problem than argus over writing PID files.
> > I mean, what prevents a user with sufficient access from doing
> > "argus -w /dev/mem"?
> >
> > >
> > > Really bad idea. How can we avoid this fundamental
> > > security problem?
> >
> > It's much a problem as giving a malicious user access. If
> > managed properly,
> > there's no chance of an administrator accidentally
> > overwriting important
> > PID files. The problem is fundamental as trusting the user
> calling or
> > configuring argus. Any program operating that assumption is
> > better off not
> > running at all.
> >
> > > I believe that httpd and the others
> > > that you mention have this flaw, without any obvious
> > > advantage. Specifying the pid directory, rather than
> > > the file, would be adequate.
> >
> > The major gain is flexibility. Making the PID file location
> > configurable
> > made my scripts easier to understand and write.
> >
> > Regards, Yotam Rubin
> >
> > >
> > > Carter
> > >
> > > Carter Bullard
> > > QoSient, LLC
> > > 300 E. 56th Street, Suite 18K
> > > New York, New York 10022
> > >
> > > carter at qosient.com
> > > Phone +1 212 588-9133
> > > Fax +1 212 588-9134
> > > http://qosient.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yotam Rubin [mailto:yotam at makif.omer.k12.il]
> > > > Sent: Tuesday, March 19, 2002 9:32 AM
> > > > To: Carter Bullard
> > > > Subject: Re: The patch.
> > > >
> > > >
> > > > On Tue, Mar 19, 2002 at 09:15:17AM -0500, Carter Bullard wrote:
> > > > > Hey Yotam,
> > > > > I'm not aware of any program that will let you specify
> > > > > the name of the pid file, do you have any examples
> > > > > in mind? How do you prevent argus from overwriting
> > > > > /var/run/identd.pid?
> > > >
> > > > Well, it looks like thttpd and mason allow the user to
> > > > specify a PID file.
> > > > Additionally, Debian's start-stop-daemon program allows it as
> > > > well, and
> > > > many scripts rely on the specific location of the PID file.
> > > > The only thing we can do to prevent argus from overwriting
> > > > other files
> > > > is to stat() the pid file before writing to it. Important
> > > > files can also be
> > > > clobbered if the user specifies a certain archive file.
> > > >
> > > > Regards, Yotam Rubin
> > > >
> > > >
> > > > >
> > > > > Carter
> > > > >
> > > > > Carter Bullard
> > > > > QoSient, LLC
> > > > > 300 E. 56th Street, Suite 18K
> > > > > New York, New York 10022
> > > > >
> > > > > carter at qosient.com
> > > > > Phone +1 212 588-9133
> > > > > Fax +1 212 588-9134
> > > > > http://qosient.com
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Yotam Rubin [mailto:yotam at makif.omer.k12.il]
> > > > > > Sent: Tuesday, March 19, 2002 8:56 AM
> > > > > > To: Carter Bullard
> > > > > > Subject: Re: The patch.
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 19, 2002 at 08:05:56AM -0500, Carter
> > Bullard wrote:
> > > > > > > Hey Yotam,
> > > > > > > I'm putting in the pid file support now, and I've
> > > > > > > got a few questions. Since argus normally runs with
> > > > > > > root privileges, specifying an arbitrary pid filename
> > > > > > > may cause some problems, writing over an existing system
> > > > > > file, etc...
> > > > > > >
> > > > > > > It would seem a bit safer if we examine the target file
> > > > > > > to see if its actually a pid file before clobbering it,
> > > > > > > but that doesn't really work, as there is nothing
> > > > > > > preventing someone from specifying that argus should use
> > > > > > > the pid file for sendmail, as an example, which would
> > > > > > > keep that application from running, if argus came before
> > > > > > > it in the boot startup sequence.
> > > > > >
> > > > > >
> > > > > > Yeah, we should probably stat() the pid file before
> > writing it.
> > > > > >
> > > > > > >
> > > > > > > Would it be alright if we allow the user to specify the
> > > > > > > pid file directory, rather than the exact file?
> > > > > >
> > > > > > Well, I find it more comfortable to specify the exact
> > > > > > location of the PID file. Also, this is common behavior in
> > > > > > other programs as well. The user probably wants a method to
> > > > > > distinctly determine the location of the pid file. Letting
> > > > > > argus select the name of the pidfile has no significant
> > > > > > benefit, and may cause errors. For example, the Debian
> > > > > > package may start argus whenever a PPP
> > > > > > interface comes up. It's more comfortable to rely on the
> > > > > > script's pid file handling, than on argus' pid file name
> > > > selection.
> > > > > >
> > > > > > >
> > > > > > > Would you support a single option for the command
> > > > > > > line pid file? Say "-n [piddir]", rather than using
> > > > > > > two options?
> > > > > >
> > > > > > I preserved the original PID file option because I
> was unsure
> > > > > > whether it was alright to remove it. It is more comfortable
> > > > > > to have a single option[1] rather than having two options
> > > > > > which achieve a similar result. It would seem
> better to leave
> > > > > > only the -c option.
> > > > > >
> > > > > > Regards, Yotam Rubin
> > > > > >
> > > > > > [1] GNU getopt() supports options with optional arguments.
> > > > > > This enables
> > > > > > to let argus select the pid file name when no
> argument is
> > > > > > specified,
> > > > > > or create the pid file at the user specified location.
> > > > > > Sadly, this behavior
> > > > > > is not portable, so if we want to use it the
> inclusion of
> > > > > > the GNU getopt()
> > > > > > is required.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Carter
> > > > > > >
> > > > > > > Carter Bullard
> > > > > > > QoSient, LLC
> > > > > > > 300 E. 56th Street, Suite 18K
> > > > > > > New York, New York 10022
> > > > > > >
> > > > > > > carter at qosient.com
> > > > > > > Phone +1 212 588-9133
> > > > > > > Fax +1 212 588-9134
> > > > > > > http://qosient.com
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Yotam Rubin [mailto:yotam at makif.omer.k12.il]
> > > > > > > > Sent: Wednesday, February 27, 2002 4:26 PM
> > > > > > > > To: 'Carter Bullard'
> > > > > > > > Subject: The patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > The patch discussed on the list is
> attached herein.
> > > > > > > >
> > > > > > > > Regards, Yotam Rubin
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
More information about the argus
mailing list