[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewall-wizards
Subject:    Re: [fw-wiz] VM system for firewall use
From:       "Paul D. Robertson" <paul () compuwar ! net>
Date:       2004-10-12 14:43:37
Message-ID: Pine.LNX.4.58.0410121033100.11205 () bat ! clueby4 ! org
[Download RAW message or body]

On Tue, 12 Oct 2004, ArkanoiD wrote:

> On Tue, Oct 12, 2004 at 10:01:51AM -0400, Paul D. Robertson wrote:
>
> > I'm a big fan of MAC compartments, but the admin overhead can be no fun.
> > Fortunately, for your usage, you just have to define the policy once.
>
> Yes, that's the point ;-)

Unfortunately, it's not always possible to have a static config- and that
gets expensive administratively.  Been there, designed that, trying to
avoid a repeat ever ;)

Things are a'moving in the trusted computing world, and it seems that
folks are doing really sane inheritance things these days to overcome some
of that, and making it easy to enforce simple models.

> > I'm really unsure as to why a jail isn't enough though--
> >
> > If the code runs on the firewall, and it is compromised, it's game over,
> > separation between processes just seems like it's not going to be all that
> > useful.
>
> Why? If the code compromised is, say, content filter that has no access to
> real hardware, just runs on virtual disk drive and talks to a kind of looback
> interface to other components, the impact is just malicious user may
> bypass this particular filter, and nothing more (there are more dangers
> in real world since if it was taken over there are more attacks to other
> components accessible from this point, but that risk can be minimized as well)

The problem is that you get into a position where the interface in and out
of the virtualization has to be hardened to provide assurance, and since
you're doing a one-off model, it's really difficult to provide that
assurance.  If I can get data in to compromise it, then I can likely get
data back out, and from there, it's an exercise in inching forward for
an attacker.  Granted, you're out of script kiddie land, but jails pretty
much give you that- so I'm not convinced that the overhead is worth-while
for sets of things that have to intercommunicate a lot (like your
examples.)

I much prefer a trusted computing base, because then the
intercommunication is labeled and the system takes care of who can see what
and what they can do after they see it.  It also scales much more robustly
than trying to cram multiple VMs into a single RM.  I could be wrong- and
there's something to be said for putting in as much protection as possible
anyway- I'm just not sure the trade-offs will be all that good.

> > >  Now, if you get MAC down into the network later, and don't allow
> > the less-trusted code access to the internal interface,
>
> Sure!
>
> > then *that* gets
> > interesting, but virtualizing the less-trusted code just seems to me like
> > it doesn't gain all that much if you can gain root (jails seem to help
> > with that problem?)
> >
> > [1]Yes, MAC on a Mac is not going to be fun to talk about without
> > confusing
> > folks.

For the curious:

http://www.trustedbsd.org/sedarwin.html

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@compuwar.net       which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
[prev in list] [next in list] [prev in thread] [next in thread]