Outstanding issues

[Darren Spruell]

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