I think the problem is that people not working with the current generation
of trusted operating systems don't understand how they work in conjunction
with a firewall to protect a system. BTW, Trusted Solaris is NOT a good
example of the current generation of trusted OSes.
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."
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().
With a trusted OS I can make my file system, or any portion thereof,
read-only to whatever processes I want, such as the web server, even if
the webserver is running as root.
Better yet, the trusted OS can provide different views of the file system
based on where the traffic is coming from (IP address, network interface,
etc.), and this view is propagated through descendent processes. I can
even have file names (and of course URLs) resolve to different files by
the OS depending on where the request came from. An "outsider" sees a
different file system structure than an "insider", regardless of the user
ID of the process or any knowledge the user may possess (passwords, keys,
etc.).
I can provide telnet access and have the OS provide different capabilities
based on where the traffic originated. That is, I can administer the
system via telnet, ssh, or http only if the I am connecting under special
circumstances. An attacker that has all user accounts and passwords
cannot successfully attack the system if the attack originates from the
wrong host or interface.
Protecting web sites from being trashed is "trivial" with a trusted OS
because that's a fundamental operation of the software.
paul
---------------------------------------------------------
Paul McNabb Argus Systems Group, Inc.
Vice President and CTO 1809 Woodfield Drive
[EMAIL PROTECTED] Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433 "Securing the Future"
---------------------------------------------------------
> From [EMAIL PROTECTED] Wed Dec 23 11:40:17 1998
> Date: Wed, 23 Dec 1998 12:51:50 -0500
> From: Bennett Todd <[EMAIL PROTECTED]>
> To: Paul McNabb <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Web server and firewall?
>
> 1998-12-23-09:59:52 Paul McNabb:
> > The solution is trivial.
>
> Solutions to trivial problems are simple. However, this is not a trivial
> problem.
>
> > Stick a trusted OS under his web server. Then he can even let people
> > telnet into his web server and they still won't be able to hack it.
>
> That could be made to work, if and only if you only want to solve a trivial
> problem.
>
> Stick a trusted OS around the web server, and configure it to prohibit
> anything except the web server from accessing the web server, and then you
> could allow people to telnet into the machine, and they wouldn't be able to
> "hack" it, whether by "hack" you mean "corrupt or sabotage", or you simply
> mean "maintain or repair". Why bother setting up a telnet daemon if you're not
> going to make the incoming service useful? Better to just disable it.
>
> But sticking a trusted OS under a web server won't help the _interesting_
> problem, which is that configuration errors --- like e.g. inadequate parameter
> checking in CGI scripts --- can allow requests made directly to the web server
> to disrupt its functioning.
>
> If the job at hand were to allow a web server and some unrelated activities to
> share a single computer, then a trusted OS would be helpful for setting up
> separate boxes for them to play in. But when the job is securing a web server
> all alone by itself on the hardware so people cannot corrupt it, the part of
> the job that a trusted OS can help with is too trivial to merit the complexity
> and cost of a trusted OS.
>
> Just shut down inetd, sendwhale, and any other daemons that are listening. If
> you have something you need to leave running and you can't prevent it from
> listening (canonical example: syslogd) slather on some packet filtering (ipfw
> for Linux, ipfilter for most anything else) tp prevent others from contacting
> that port. Check your work with "netstat -a".
>
> -Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
