firewall-wizards Digest, Vol 64, Issue 10

Send firewall-wizards mailing list submissions to
firewall-wizards@listserv.icsalabs.com

To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com

You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."


Today's Topics:

1. Re: Choir, preaching to (was Re: Proxy advantage) (Marcus Ranum)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Apr 2013 08:19:38 -0500
From: Marcus Ranum <mjr@ranum.com>
Subject: Re: [fw-wiz] Choir, preaching to (was Re: Proxy advantage)
To: firewall-wizards@listserv.icsalabs.com
Message-ID: <516FF2EA.2060305@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Bennett Todd wrote:
> A low-tech kludge for must-have apps with unacceptable security issues
> is to run them on a sandbox machine. Happily, in this day of VMs, the
> cost of doing so is smaller than it used to be.

I remember "back in the day" when some of us recommended
running dangerous stuff on disposable machines, with the
execution context under 'chroot' or whatever. Today's
version of that is a VM - but the problem is that the VMs
are seldom as stripped-down as a 'chroot' environment.
Consequently, there are problems.

One of the big problems I have with VMs is that the
guarantee of isolation that the VM theoretically provides
keeps getting broken. Remember - the kernel barrier
between the O/S and the applications is also supposed
to be inviolable, and the Windows-using community
has been writhing with pain for a decade+ over the
consequences of breaking down that barrier (because
it was a pain for users, of course) (it was also a pain
for malware, of course) I'm not confident that the
same fools who made the decision to make the
kernel barrier permeable aren't going to make the
VM barrier permeable, as well, for exactly the same
reason. And with exactly the same results.*

Another problem with the idea of "must have" pieces
of bad code is that since they are "must have" they
wind up being critical and cannot be trivially
reverted or rolled back. It's one thing if we're talking
about a nameserver (which is simple, relatively
static data) but it gets vastly trickier when that crappy
app is trying to update your backend databases.

mjr.
(* Yes, we're already seeing them)

--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenable.com



------------------------------

_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


End of firewall-wizards Digest, Vol 64, Issue 10
************************************************