Outstanding issues

[Carter Bullard]

Hey Russell,
These strategies are no different than argus just restarting.
This is because we have privilege issues in all aspects of argus
processing except the flow tracking, and as I mentioned earlier,
we don't have the opportunity to have multiple processes, so
not really a possibility.

Argus has to open the packet interface before it chroot's, (/dev/eth0
won't exist in the chroot'd directory structure) and it has to get to  
its
configuration file to figure out if there is a specific interface to  
open.

If tcpdump offered a privileged socket where you could attach and
get packet dumps, then it would look more like argus than it does.

I think we'll be able to do this, just will not be ideal.

Carter

On Sep 25, 2006, at 5:38 PM, Russell Fulton wrote:

> Carter Bullard wrote:
>
>> DO NOT ask us to chroot(), then read the system configuration file.
>> That would be stretching it quite a bit I think.   We don't know  
>> which
>> interface to open until we've read the configuration file, so  
>> thats right
>> out.
>
> Actually, if you use the Open BSD model you can do stuff like  
> this.  As
> Eric points out they can maintain one process that retains privilege
> that can control the child that does the dangerous stuff.   So you  
> cn do
> things like signal the parent to re read conf and then restart the  
> child
> (or feed it the changes via a pipe).
>
> As I said in an earlier post I think this model is overly complicated
> for the likes of argus and snort.  It is great for servers like SSH
> which is what it was designed for.  They have applied this model to
> tcpdump but that, I suspect, was simply because they had the model and
> were already thoroughly familiar with it so the additional work was  
> not
> much of an issue.
>
> Cheers, Russell
>