Outstanding issues

[Carter Bullard]

Hey Darren,
No, no, no!!!!  The higher level discussion is more important than any
implementation discussion.  We can implement anything.  The hard
part is deciding what to implement.

The only thing that I think is a barrier is the notion that all of these
chroot() approaches assume that privileges are used only at
initialization.  What if you need to regain privileges at a later time?

Are there discussions as to how to approach this?  We can't go back,
and any strategy that would allows us to do so, even virtually,
is open for exploitation, as the markov analysis will show.

I can live with reality, whatever the outcome, but if someone has
an acceptable approach that would allow us to get back privileges
temporarily, when chroot is used, I'd like to know about it.

Carter


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

> On 9/25/06, Carter Bullard <carter at qosient.com> wrote:
>> 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.
>
> Understood, especially where that impacts core design goals.
>
>> 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?
>
> Only when I think of compromise containment if argus has started a
> listening socket. Having shed root privileges, if chrooted to say an
> empty directory, I'd say the worst case scenario of a remote
> compromise is significantly lessened in scope. In cases where argus is
> simply outputting to a file and there is no daemon accessible from
> outside the host, it has little merit.
>
> I think I'll pipe down now, as I have an idea of what I'd like to see,
> but very little practical understanding of what the situation is that
> makes it work practically or not.
>
> -- 
> 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/de1f69a3/attachment.html>