Outstanding issues

[Carter Bullard]

Hey Darren,
No problems, you're new to the list, and in  discovery mode.
Argus has been around for 12 years as an open source program, and
we, on the developers list, are software engineers/programmers
( do any of us still call ourselves programmers? ) all capable of doing
the simple stuff.  Just need to understand if there is really something
to do.

Chroot() is not a universal security mechanism, if it was you wouldn't
have to go to the lengths you have to do to "jail" some of the programs
that you have on your list.  Some people do like it, so we should at  
least
support it at some level.  But, architecting a piece of software just to
allow chroot() is not necessarily a good idea.

Argus has 3 basic functions, two need privileges (*), when running  
default.
    1. Read packets (from either a live interface* or a file).
    2. Track flows
    3. Output flow records (to either a privileged*/non-privileged  
socket or file).

Over the years we have implemented Argus as a single process, multiple
processes, multiple threads and as a single thread (in chronological  
order).
The motivators for all of these has been programatic control vs  
performance.
Currently, for high performance, multiple threads is the best on  
certain platforms,
single thread on others (where scheduling is poor).  But multiple  
processes
is NOT a good design, because of the memory copies needed to move
records from one process to the next, or when running on shared memory
machines, the process overhead gets in the way.

The fundamental issue is, what to do about the order of privileged  
operations.
We need to do the privileged operations on devices and the file system
before we do a chroot().  And really, once we do the chroot(), we  
really don't
want to go back, so to speak.  In most installations, argus opens a  
device
and a privledged socket, and syslog, and thats it.  It never opens  
another
device, doesn't create output files, and only services sockets that  
it has
opened.  When this is the case, does chroot() make any sense at all?

Carter


On Sep 25, 2006, at 1:44 AM, Darren Spruell wrote:

> On 9/24/06, carter at qosient.com <carter at qosient.com> wrote:
>
> [snip]
>
>> (Still thinking about a general approach to the chroot/user/group  
>> issues).
>
> [snip]
>
>> If anyone has comments, please holler, and thanks for all the  
>> help!!!!!
>
> Just the above, namely the chroot/user issues. There'd been some good
> discussion recently regarding the semantics of exactly how to handle
> that.
>
> I'm not a programmer, but I'd very much like to see that succeed.
> Available for testing of course. Regarding strategy, most of what I've
> seen thusfar done has been on OpenBSD which as a platform places a lot
> of emphasis on reducing exposure for daemons that require some amount
> of root privileges by one of two methods; privilege seperation and
> privilege revocation. The first involves splitting the functionality
> of a program out into two seperate processes, one that runs the stuff
> requiring higher privileges as root, and one that runs as a lower
> privileged user to carry out the non-privileged functions. Privilege
> revocation involves a single process which is launched as root to do
> the root stuff and once the privileged startup stuff is done, changes
> uid over to the non-privileged user.
>
> If it's worth anything, reference code in OpenBSD is open and easily
> found (http://www.openbsd.org/cgi-bin/cvsweb.cgi) and several programs
> make use of these features.
>
> tcpdump(8)
> dhclient(8)
> dhcpd(8)
> pflogd(8)
> syslogd(8)
> ntpd(8) (OpenNTPD)
> ftp-proxy(8)
> httpd(8)
>
> 3rd party apps that handle it as well come to mind:
>
> snort(8)
> openvpn(8)
> named(8)
>
> And to be clear, I hope I'm not talking down to anyone here. Simply
> hoping to get things rolling where the work's been done before...
>
> -- 
> Darren Spruell
> phatbuckett at gmail.com
>

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20060925/1d4103a2/attachment.html>