argus in chroot, privilege seperation/revocation

carter at qosient.com carter at qosient.com
Wed Sep 20 07:39:29 EDT 2006


OK, so this helps a lot, but I am confused as to the goal.  Are we trying to prevent argus from creating output files as root, but still be able to read its configuration file, open any packet interfaces and output sockets with priviledges?  Are we chroot'ing only to control file creation paths, or to also control from where argus reads its data?  Are we worried about where argus creates any dump() files and who owns these?  All of this tends to dictate the order of things, of course.

I'll break out these options, open the interfaces or all the input files and any output sockets, ..... then just before processing the first packet, chroot(), do the setuid() and setguid(), and then open() all the output files?  

There is a notion of defered opens for interfaces that have gone down!  I suppose if I have to retry opening the interface, I'll have to "un-chroot" so that I open the real /dev/whatever0 ?  That doesn't sound quite right!!

We create the output file as argus parses its options, because its possible that argus doesn't generate any output for a while, and its pretty weird for it to run for say 60 seconds (mar status interval), and then die because it can"t create its output file!

I'll have to add these to the argus.conf file! Work, work, work, work, work, work ;o). Send opinions as to what this is trying to achieve!!!

Carter

Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax  

-----Original Message-----
From: Andreas Östling <andreaso at it.su.se>
Date: Wed, 20 Sep 2006 10:18:49 
To:Carter Bullard <carter at qosient.com>
Cc:Argus <argus-info at lists.andrew.cmu.edu>
Subject: Re: [ARGUS] argus in chroot, privilege seperation/revocation


On Wednesday 20 September 2006 07:24, Carter Bullard wrote:
> Hey Andreas,
> So I have a few issues/questions regarding your patch.  No problem,
> just need to find the right approach.  When the "-C dir" option is
> used, along with  the "-w outputfile" option, how do we ensure that
> we chroot before we process the output file option, which causes us
> to create the file.  Same with your "-u user" or "-g group" option,
> since these could affect whether the output file can be created or
> not.

I remember dealing with this issue now when trying the patch on Argus 3 
on some early RC. I made some simple change to fix it but unfortunately 
I can't find that patch now. If i remember correctly Argus opened the 
-w file file twice (first time just an open/close to create it) and I 
never understood the point of it so I think I simply removed the first 
one. Of course if the chroot/privilege drop happens before the 
remaining open, -w file is opened relative to the chroot dir and the 
creation/open is done as the unprivileged user. I personally don't 
really mind how it's done as long as it's documented.

As a side effect you could then start Argus suid root again. Not that I 
would do that but I supposed you should be able to since there are 
already some setuid(getuid()) in here. That stuff broke things in a 
similar way since Argus would create the output file as root, drop 
privileges, and then fail to reopen it as the real user. But again this 
was some early RC and I don't really remember the details.


> Can I use the "-u user" option without using the "-g group" option?

As you noticed I added a test so you must specify either none or both.
Specifying only one of them doesn't really make sense to me but
technically there is no reason why you couldn't use -u without -g.

/Andreas




More information about the argus mailing list