Marcus,
>
> >I can just as easily run B1 unix w/o network daemons if all I want to
> >live w/o proxies. If you proxy in DOS or windows, then the OS has
> >absolutly no protection from software errors.
>
> [I may get the orange-bookspeak wrong, but I'm sure some kind
> soul will correct me if I do]
>
> My impression is that in orange book land, a proxy is a
> "trusted process." It takes advantage of the features of the TCB
> (Trusted Computing Base) that protect the system, but, because it's
> moving stuff around, the designer is trusting that it does at least
> some of that stuff right. But if there's a software error in the
> proxy, then it's just as much a problem as if there's a software
> error in a proxy on an un-orange book system. Of course, a trusted
> process' software gets carefully evaluated and formally modelled
> and all that stuff, too. But if there's a flaw, it is still a
> potentially fatal flaw.
Not true. Of course we trust the proxy to do those proxy
things that it does so well, but we don't trust it to modify the
underlying OS. In an MLS system, we can create as many rings or
layers of protection as desired. Each higher level ring can rely on
the lower levels' services, but cannot write to them.
Typical Setup 1:
Levels
1 proxies and other applications, webservers etc.
---------------MAC barrier--------------------------
0 TCB, including audit trails, config files, cron scripts,
devices etc
This setup lets the proxies run above the operating system level.
Thus a proxy flaw is no more serious than a login at level 1. The OS
is protected from all modifications and trojan horses. Even the root
password would do no good. Further more, we will be able to securely
monitor the operation of the proxy and all processes that spawn from
it.
Typical Setup 2:
Levels
2 proxies and other applications, webservers etc.
---------------MAC barrier--------------------------
1 proxy code and configuration stuff
---------------MAC barrier--------------------------
0 TCB, including audit trails, config files, cron scripts,
devices etc
This setup would protect the proxy's code and config from the actual
running daemons. Proxy Administration would occur at the protect
level 1 w/o jepardizing the OS.
More complicated models are available that would protect the proxies
from one another so that proxy-ftp would never be able to modify proxy-telnet's
behaviour and so on. I haven't looked at the Type Enforcement
model, but something tells me that its capable of the same type of
protection. Were can we get some details of how TE works? Rick, Care to
post a couple of setups like the above?
> Put another way: if you run plug-gw for telnet between * and
> your inside network you're still wide open, B1 or no B1.
>
> This is why I keep urging people to recognize that there are
> TWO (at least) protective relationships that a firewall embodies.
>
> How well it protects itself from attack
> How well it protects its network from attack
Is it too much to imagine that protecting itself from attack helps it
protect the network from attack?
>
> All the orange book protections help with the firewall's
> protecting itself from attack, but don't do anything for the
> network, unless you're running B1 on the inside network, and
> labelling and a complete trusted environment. Most commercial
> networks don't do that, and won't ever do that. And if they do,
> they'll rip it out in 2 years.
>
> So: consider that the firewall must protect the helpless
> machines behind it, which are running SunOS, AIX, and Windows for
> workgroups + IP. :) Now, the question is: what does my firewall
> do for them? The B1-ness of the firewall at that point is totally
> irrelevant. What's now important is whether or not the mailer
> blocks out "| sed '1,/^$/d' | /bin/sh" as a Reply-To address,
> and whether the trusted FTP service on the firewall binds ftp-data
> when it talks to the inside, and so on. Those details are reflected
> not in formal methods, but in niggling, ugly, policy reflected in
> lines of code.
Of course, you still have to install a firewall of choice on the B1 host.
B1 protects the firewall host itself from attack. I think that that is in
and of itself enough reason to implement firewalls on B1 servers.
Now Padgett mentions using DOS to kick off a machine-model piece of
code that uses the protection of the MMU just like UNIX, NT, and other
virtual memory OS's do. I'm sure that you can indeed build a secure
firewall in that fashion, and with sufficient work could get it
evaluated against someone's criteria. Consider what will have to be
done. You'll need some way to schedule services, maybe interrupts will
do? You'll need some way to enforce separation of kernel from services,
maybe using a protect mode in the CPU will do. But that only protects
memory, the access to devices and files is still wide open, You'll have
to have some way of determining when one of the services modifies something
upon which the kernel relies..whew! I'm getting tired thinking about
it.
But this exhasting work has already been done! We have B1 secure versions
of operating systems that use the hardware protection mechanisms to
separate processes from one another and the kernel from processes in
general; B1 policy to protect files, Auditing to record accesses and
detect failures. They have been through rigorous evaluations.
Now vendors will cook up their own solutions, and firewalls are in
their infancy, but we should build on the work that has been done when
it comes to operating systems.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
References:
|
|
