On Mon, 28 Dec 1998, Bennett Todd wrote:
> 1998-12-23-20:58:07 Paul D. Robertson:
> > The main difference is that with a trusted OS, you can *really* determine
> > what files and network resources can be changed. There's no reason in
> > the world for a CGI to call /bin/sh (unless it's written as a shell script),
> > and having the ability to restrict things like that irregardless of
> > exploitable code means the scope of vulnerability is limited to whatever the
> > *administrator* allows, not whatever the CGI programmer allows unless the
> > admin wants to extend that trust, including interpreters which have bugs,
> > stack exploits, and even executables that you may wish the programmer to be
> > able to execute when telnetted, but not through a Web browser (important if
> > you mandate a strong authentication method for shell access for instance).
>
> I think I'm still missing the point here.
It would apear so.
>
> The normal setup for a reasonably-secure web server restricts access of CGIs
> using normal unix permissions, running the CGIs as a non-priv user. Beyond
> that you can tighten down a bit more without breaking the functionality of the
> CGIs, but not a while lot; if you've made reasonable use of unix permissions
> and multiple hosts when setting up your web server, the CGI doesn't have the
> potential to get at anything more important than the data it _must_ be able to
> interact with to do its job, already.
>
> Sure, if you want to add the complexity of a MAC-supporting hacked-up OS to
hacked-up is a bit of a stretch.
> your pile of bits, and you completely trust the "trusted" OS's implementation,
> then you can do the above and also let random swine telnet into your server as
> "guest" --- but why bother?
It depends on what you have to lose, and what the machine needs to do.
The point, of course, is that in having a system which doesn't allow an
untrusted shell user to compromise it _no matter what_ they do or have
(including the root password) gives a significantly higher ammount of
protection than a GP OS. Yes, you have to trust the TCB, you also have
to trust a normal OS' kernel to do the right thing.
> > Does that validation makes more sense in the OS than in the CGI?
>
> The question is, does it make sense in the OS _at_all_? The CGI still has to
> be able to get at the data it manipulates; if the OS is gonna prevent that,
> why then let's get even simpler and delete the CGI. So if you've designed a
> good setup where the only data the CGI can get at is the data it has to be
> able to get at (and less-important stuff), then the only remaining recourse
> is to audit the CGI to make sure it can't be fooled into doing inappropriate
> things with its data.
This doesn't address a plethora of potential CGI problems though. Also,
there's the question of CGI auditing. In a TCB-based environment, you
simply need to give the developer access to certain MAC levels and
let them do their job. It doesn't matter if they slip up, if they're
intentionally malicious, if their compiler was trojaned, or if someone
breaks their machine, you're assured that the only thing the CGI can access is
whatever files it needs to do its job. No worries about exec() calls, shells,
newly installed software, setXid() processes/files, chroot games, buffer
overflows in libraries, host.equiv, .rhosts, kernel modules, /dev entries...
>
> > On a general purpose OS, a CGI bug generally means access to root if any
> > damage can be done at all.
>
> I find this statement ingenious; yes, there are certainly general-purpose OSes
> that are that bad, but the apparently-similar statement starting "On _any_
> general-purpose OS..." I do not buy. I can secure any well-maintained
> Unix-like OS --- e.g. Linux, or one of the free BSDs --- so that a breach of
> CGI can't be escalated to root, and I can do this really easily, far more
> easily than anyone could even _order_ a Trusted OS, much less receive it, open
> the shrink-wrapped packaging, install it, and configure it.
Ordering a trusted OS is a single phone call, installing is not much more
involved than installing a non-trusted varient in my experience
(obviously implementations vary, it's the same with untrusted OSen).
Configuring it isn't simple, but most of the defaults in the system I'm
most familiar with are reasonable.
>
> > That's not true of a trusted OS that's properly configured, *especially* if
> > the HTTP server is part of the TCB.
>
> It's more or less true of a trusted OS insofar as the trusted OS has fewer or
> more bugs that compromise its design assumptions. Given the number of
> developers supporting the trusted OS, with access to its source code, I'd tend
> to assume more design-assumption-violating bugs will be found there.
Given the process of evaluation, and depending quite a bit on the clue
factor of the evaluation team, there's a significantly higher ammount of
validation and design review than on a non-trusted OS. Reading the
Interim Evaluation Reports as well as the FER should help to gauge the
level of work that was put into play.
Given that the TCB permeates, in general terms, bugs outside of the TCB
structure shouldn't have a great deal of effect as long as the trusted path
and MAC levels are set appropriately.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
