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.
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
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?
> 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.
> 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.
> 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.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
