1998-12-28-18:32:50 Paul D. Robertson:
> If a CGI only has a MAC level as a Web server child, the typical attacker
> making a shell won't matter.
If a CGI has to be able to manipulate some data (the typical case, no?), then
an attacker who successfully compromises the CGI will be able to compromise
the data behind it. If it's read-only access being provided, then an attacker
who successfully violates the CGI will be able to cause it to present
different data to the user.
The point is that the CGI is supposed to be doing some useful job, and
ensuring that it can is not assisted by a trusted OS, except as one mechanism
for sandboxing.
> > [...] But once you've partitioned your problem you _still_ have to audit
> > those CGIs; protecting the data that the CGIs must access from defects in
> > those CGIs is not a job that a trusted OS will help with, and it's the
> > only hard part of the problem.
>
> Defects that can be exploited, certainly it can help.
No, the most that a trusted OS can do is guarantee that the _only_ thing a
violated CGI can do is mutilate or mis-represent the data it's responsible for
--- a guarantee that can also be constructed with more common, widely-used
mechanisms. And my point is that the hard part of the problem is auditing that
CGI to ensure that it cannot be fooled into doing the Wrong Thing, and that
job isn't helped by a trusted OS.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
