Outstanding issues

[Carter Bullard]

Hey Russell,
Well, the only thing that chroot() will prevent us from doing is
reopening a down interface, or re-reading the system configuration
file, if we set the signals to do the right thing.   I can live with  
that,
but it is not at all desirable.

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.

I'll have to have delayed opening of some things, but if the notion
is that we're just controlling output file generation, I maybe able to
do this in a short period of time.

Seems like we'll have to change how we use syslog, as we current
call openlog() and closelog() in each ArgusLog() call, and that won't
work if we're chroot()'d.

Carter


On Sep 25, 2006, at 4:09 PM, Russell Fulton wrote:

> Carter Bullard wrote:
>
>   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?
>>
>
> Chroot makes sense in that it is a fairly effective defence against
> automated attacks.  Programs that delve into packets on the wire are
> vulnerable to bugs in the code that deal with those packets.  Snort  
> has
> had bugs of this nature some of which lead to code execution.  Such
> network sensors make a tempting target for the current attacker as  
> they
> can't be firewalled and once compromised you have a secure base inside
> the network.
>
> Simple chroot to the directory where your data files are makes it very
> difficult for an *automated* compromise to establish control over the
> machine or do anything like scanning.
>
> I class being able to chroot the server as being desirable but not
> essential.  If it can be done without much effort then I believe it
> should be.  The jail does not have to be foolproof, I would be happy
> with anything that makes automated attacks too expensive to be  
> worthwhile.
>
> Cheers, Russell
>

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/bfdb488b/attachment.html>