>
> I have to say up front that I agree with MJR.
>
> Hardening and creativity in your OS are great for a firewall, however a NCSC
> just isn't directly enough applicable.
>
> >Can you explain how the "hardened" OS helps? If the firewall
> >software is implemented below the OS layer (e.g.: some kind
> >of adaptive filtering or whatever) then the OS will never even "see"
> >the traffic at all and whether it's an evaluated OS or not is
> >completely irrelevant. If the firewall software is purely application
>
> I don't even think that this is totally valid argument in MOST implementations.
>
> True that in a MLSI firewall this conceptually is true, however people love
> to add 'stuff' to there firewalls. Stuff like mail handlers, DNS servers,
> HTTPDs, etc.. As soon as they do that this stuff becomes the week link in
> there system.
> While I would imagine that some exist I don't think I have seen any yet
> configured as solo systems.
>
> The villain exploits one of the above and is then on the box. At that point
> a trusted OS is unlikely to help. Those processes all too often are run as
> root (Yes I know that they shouldn't, don't need to, could fork, etc...but I
> am talking what far to many people end up running) and leave the villain
> free to go on in.
Well, true and not true. (To be redundant, anything below B2/E4 is not
trustworthy.) Just because an OS is high assurance (B2/E4 and above), this
doesn't mean that it protects against all things. At best, it only does
what it claims to do and no more.
To solve this stated problem, the claim must be that you can run untrusted
software in a specific "area" such that if the untrusted software is
penetrated, the damage is limited to the maximum authority available in the
"area" the software was running in.
This concept is included in B2 DG/UX and is called "containment." The
claim is that when a user enters the system, a maximum "containment area"
is assigned to him which can never be extended. When a user is connected
to a service such as a web server, that web server is running in the user's
containment area when it services the user.
(In brief, the concept of containment is that the system is divided into
two parts, that which exists for the user and that which simply does not
exist for the user, so there is no way to get to it. Containment is
further divided into "sub-containment" areas which define the access rights
the user has - read only, write only, read write, etc. This applies to
both objects AND to operations. Operations are things like halting the
system, stopping auditing, changing a user profile, etc. There are an
arbitrary number of containment areas on a system, and they do not have to
be predefined - you roll them as you go.)
Thus, if the application breaks, and the user escapes to some user
interface (shell, CLI, etc.), the user has no more authority than he had in
the application, and he has no way to gain any more, regardless of what
passwords he knows or what smart cards he possesses or whatever. Even
operating system applications (init, login, etc.) cannot break containment
- that is the only way that containment could possibly work.
So a high assurance containment OS CAN provide what is being asked for.
And when you run web servers and Java interpreters on the high assurance
containment OS, it doesn't matter whether it is Unix (as is DG/UX) or NT or
ABC. Go look at DG next time you are at a trade show.
BTW, I am the security architect for DG and architected this OS, so this
information is correct. Of course, every father's child is beautiful and
intelligent! :-)
>
> How about an OS that fingerprinted all its apps, or added extra file
> attributes (not generatable during run-time operation) that were necessary
> for execution. Then if the kernel didn't see this stuff it shuts down.
> This way you could delete from the PRODUCTION system all likely tools
> (chown, chmod, telnet, rxx, mknod, ifconfig, route, etc) and if the villain
> tried to add his/her own the box would croak. I would take that type of
> hardening over B1 any day. (Yes you need a non production IE no network
> code kernel for maintenance mode.)
>
>
> -Charles Kaplan
>
>
--
Jon F. Spencer spencerj @
rtp .
dg .
com (uunet!rtp.dg.com!spencerj)
Data General Corp. Phone : (919)248-6246
62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108
Research Triangle Park, NC 27709 Office RTP 121/9
Reality is an illusion - perception is what counts.
No success can compensate for failure in the home.
President David O. McKay
***** UCC 1-207 ********
Follow-Ups:
|
|
