On Wed, 23 Dec 1998, Bennett Todd wrote:
> 1998-12-23-15:00:06 Paul McNabb:
> > I can set up a network service (such as telnet, http, ftp, etc.) so that
> > the process can never get access to certain hosts, network interfaces,
> > other processes (via signals or other IPC mechanisms), files, devices,
> > etc. This denial of access extends to anything this process does or that
> > is handled by a descendent process through any combination of fork() and
> > exec(). The design of the trusted OS is such that you can give away a copy
> > of the hard disk and all source code for the OS and all other binaries, and
> > even with all account names, passwords, and encryption keys, and a person
> > still can't "break in."
>
> Great. But why go to the effort of using a trusted OS, and configuring it to
> allow logins, then use the trusted OS to prevent those logins from doing
> anything to the web subsystem; better to just disable the logins, and you can
> do that without a trusted OS really easily.
The effort has to do with compartmentalizing access. The point being
made above, and it's not true of general purpose OS' is that you have to
use the right access path, authentication mechanism, and be on the right
account to do _x_ for any value of x. The extrapolation of that point is
that you can have a Web developer write a CGI that calls /bin/sh, but
have it be completely useless as a CGI. You can't get around the
restrictions will shell code, bad programmers, or evil products.
> > With a trusted OS I can have my CGI scripts running in such a way that
> > they cannot access any file on the system or send or receive packets on
> > any network interface. Of course this extends to any process that descends
> > from a CGI script through any combination of fork() and exec().
>
> Cool. Useless, but cool. If the CGI can't interact with any files or network
> ports, it's just an over-complex way to croak out some static content.
> _Useful_ CGIs need to interact with local files and/or network resources. And
> the ability they may have to damage those resources is what needs to be
> protected against, and that protection requires thought and analysis, and
> isn't going to be helped by a trusted OS.
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).
> If the job at hand is to prevent the CGI scripts from being able to interact
> with the local filesystem or remote network interfaces, then yeah, it's
> trivial to do with a trusted OS. But it's trivial to do without one, too ---
> just remove the CGI. If on the other hand the CGI has to do some substantive
> and interesting work, then there's no way around it, you have to validate its
> handling of the information it gets from the network, and make sure it does
> the right thing and not the wrong thing.
The questions are of course:
Does that validation makes more sense in the OS than in the CGI? In the
OS, it can't be circumvented, in the CGI you have to extend more trust to
more people, and have a high degree of trust in the CGI itself as well as
its execution mechanisms.
and
Can that be maintained even when there's a bug in the CGI or interpreter, or
even library code (etc.)
On a general purpose OS, a CGI bug generally means access to root if any
damage can be done at all. That's not true of a trusted OS that's
properly configured, *especially* if the HTTP server is part of the TCB.
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.]
