On Tue, 29 Dec 1998, Bennett Todd wrote:
> 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
That depends on the data and "compromise". For instance, a write-only
file with transaction boundaries can have additional transactions
inserted, but you've a strong enough audit trail to provide a roll-back
situation, especially if the httpd checks user credentials. In that case,
the scope of vulnerability is a particular user, not every user who calls
the CGI.
> who successfully violates the CGI will be able to cause it to present
> different data to the user.
Again, not necessarily. If the MAC to change the CGI or its data isn't
extended to the httpd's path, then no they can't.
> 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.
Um, yes, that's the point.
>
> > > [...] 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.
That's wrong though. Mutilation can be stopped in most transactional
cases (extraneous transactions by an authenticated user are the only
vulnerability that really doesn't have an "answer"), and the interactive
cases where it can't, that mutilation can be limited to the scope of a
single user. While it's possible to attempt to do the same thing on a
non-trusted system, you're left with application level security which may
possibly be surmounted by a problem in something else running on the same
host (eg. a nameserver, mail server, rogue user...) With a trusted OS,
you can get that user-level enforcement irregardless of the application
set, libraries, etc.
The job of fooling CGIs is helped by a trusted OS because the MAC level
assigned to the particular access path can be limited to nullify most
damage other than that of multiple transactions per authenticated user.
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.]
