On Mon, 28 Dec 1998, Bennett Todd wrote:
> How about "single set of data all of comparable value managed by a common set
> of code" server? May be multiple cgis, if that's the simplest and clearest way
> to implement the desired access --- probably will.
"Comparable value" isn't something that I try to design for, I'd rather
that each data owner had compartmented access and control over who
(including administrative staff) could see their data. I'd also rather
have distributed administration capability and that tends to scale better
with a strong system. Compartments, physical and logical all come with
the benifits of limiting scope of errors and compromise, increased
autonomy at the policy and operational level, and at the cost of
increaded administrative forethought, higher cost and decreased
communications between compartments.
Just like firewalls, the increase in setup complexity is offset by
needing to do less day-to-day work once it's done.
> Like I said, you're conflating "value" with "privilege". Sure, the admin's
No, you're missing the point.
> privs are the most potent, everything scales down from there. But on a
> well-partitioned set of systems, the data that is managed by the CGIs should
> be the most valuable data in sight; you don't want anything more valuable left
> where it is subject to compromise if there's a bug in the CGIs. Limit the
If a CGI only has a MAC level as a Web server child, the typical attacker
making a shell won't matter. If the CGI creator needs to use a certain
path to make changes, replacing the CGI via the CGI mechanism or even
{telnet,ssh,rsh...} outside of that path won't be possible
*even_with_the_creator's_credentials*.
> damage as much as you can, whether by spreading the problem over a suitable
> number of servers or by packing it all into one and then hoping a trusted OS
> does as good a job of partitioning. 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. Defects in
function are a matter for QA not audit.
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.]
