On Mon, 14 Aug 1995, Rick Smith wrote:
> David I Dalva <dave @
TIS .
COM> wrote on type enforcement:
>
> >Type enforcement gives you a firewall that is strongly resistant to attack on
> >the machine *itself*.
>
> True. On Sidewinder, we use this to provide familiar network software
> and sophisticated proxies while controlling the risk inherent in
> running complicated server software. Sidewinder is probably the only
> firewall that runs sendmail because it's the only one that can run it
> safely, despite its bottomless list of bugs. History has shown that
> you can't predict where bugs will hit. With a nonbypassable access
> control mechanism like type enforcement, there's still protection in
> place even if the bug can't be patched immediately.
A better approach to containing huge, buggy beasts, is not to run them at all
on the firewall. Running sendmail with type enforcement still doesn't
protect your inside machines from trojan horses in mail addresses, for
example. In my opinion, any software that talks to potentially hostile nodes
should be "security" software. This "security" software, of course, is also
vulnerable to bugs/security holes, which is why it should run with least
privilege and limited access to the operating system (e.g., chroot).
Implementing the latter with type enforcement is one way to do it.
> > The key here is that it does nothing for protecting
> >your inside network beyond protecting the proxies from each other and the
> >firewall's operating system from the proxies. It's the proxies that give you
> >a degree of internal network protection. If they're good, you're protected
> >from direct attack. If they're not, type enforcement won't do anything for
> >you. (Consider a telnet proxy that uses reusable passwords for authentication
> >from untrusted networks).
>
> On the other hand, if the proxy (written by someone as a concept
> demonstration and then turned rapidly into a "product") has a flaw in
> it, type enforcement restricts the amount of damage the flaw might
> lead to. On a PC, the flaw might give "them" your machine and your
> inside net, all in one step. On a Unix box they might have to break
> root (how hard is that to prevent, eh?). Type enforcement can't be
> turned off while the system is operational and they can't bypass it.
Mandatory access control facilities, such as type enforcement, are a good
thing. My point is that type enforcement is not your first line of defense:
the proxies are. Type enforcement is the "belt and suspenders" that makes
you feel better about the software you're running on the firewall. To say
that a firewall with type enforcement is inherently more secure has no
technical merit. Less technical people may be impressed because they don't
understand it :-)
> In any case, you have to look at ASSURANCE. What does the vendor do to
> ensure the system works as stated? It's an important question to ask.
You're absolutely correct, and this is a very important point. Most vendors
can't say anything about the assurance of their firewalls. Type enforcement
is one way to increase the assurance of your firewall. BSDI's security
levels are another. Philosophy of design and implementation is another.
Type enforcement is a more brute-force method since you don't have to worry
as much about your design or implementation.
> >If you're using a firewall that has well-written proxies that run with minimal
> >privilege, don't perform disk I/O, and are easy to analyze at the source-code
> >level, you're very well protected and type enforcement becomes a marketing
> >bullet.
>
> If the firewall doesn't do much, then it's not applying much
> protection anyway. If you need a sophisticated firewall, the firewall
> needs sophisticated protection.
I don't really understand what you mean here. What functionality does
Sidewinder have that other firewalls don't? If you're referring to content
filtering via assured pipelines, that's a can of worms I'd rather not get
into :-)
Dave Dalva <dave @
tis .
com> Trusted Information Systems, Inc.
+1.301.854-6889 Glenwood, MD 21738
+1.301.854-5363 FAX
Follow-Ups:
References:
|
|
