----------
> From: Tim Newsham <newsham@zang.kcc.hawaii.edu>
Quoting Andy quoting David Jeske:
> > >Is this an official term? I have seen Andy refer to this as "VSTa
protection"
> > >and such too. I read one of the Plan9 papers which didn't make any mention
> > >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that
> > >especially in the VSTa white paper, "Capabilities" seems to be
almost a proper
> > >term for the VSTa system of security.
> >
> > Nope, this is unique to VSTa.
>
> If you're refering to the term "capability", this is a common term.
> I've run across it several times before running across VSTa.
> In _Operating Systems - Design and Implementation_ A. Tanenbaum
> talks about a 2-dimensional table where the rows specify domains of
> execution and columns specify various objects. The entries in the
> tables are the rights. He first covers ACL's which are column slices
> of the table. Then:
>
> "The other way of slicing up the matrix... is by rows. When
> this method is used, associated with each process is a list of
> objects that may be accessed, along with an indication of which
> operations are permitted on each, in other words, its domain.
> This list is called a capability list, and the individual items
> on it are called capabilities." Section 5.5.3, page 293.
Quoting "Glossary of Computer Security Terms" (NCSC-TG-004)
A protected identifier that both identifies the object and specifies the
access rights to be alowed to the accessor who possesses the capability.
In a capability-based system, access to protected objects such as files is
granted if the would-be accessor posseses a capability for the object.
[ Im assuming some (standard) technical solution is used to stop simple forgery
and copying of capabiliites. ]
Any system based on rows of the matrix can be problematic, there is are two
obvious problems:
revocation - you dont know who has access so how do you revoke it.
scalability - for a large system the number of capabilities that must be
maintained for a process is also large
In regard to the ideas (Andy, Dave, et al) of making VSTa a "very
secure" system.
Security is basically risk management, until VSTa is used in a critical
area the
risk is small and consequently the security is great. :-)
However in high risk areas (banking ...) I am not convinced the security system
currently in place will suffice for the proper assurance of confidentiality
(non-disclosure), integrity and availability.
[ The so called C-I-A triangle, because it is normally seen as a 3 way
trade-off. ]
Some details on problems of risk management (security):
The problem of availability is sometimes divided into protection against
denial-of-service (DOS :-) attacks and reliability issues.
I'll leave reliability aside until VSTa goes commercial :-), but DOS
attacks are
normally aimed at limited resources - network, memory, disk, CPU, etc.
Non-disclosure is normally an issue of simple Trojan horses, covert
channels (unintended information channels) and users incorrectly
setting their permissions.
Integrity is often seen as the 3 fold question of data, program and
user integrity.
Program integrity relies on assurance that only "good" programs are used to
create "good" data. This requires both the validation of programs and the
identification of those programs that have met the desired assurance level.
[ eg you could have 2 sort programs, 1 that appears to be correct and
is really quick,
and a second you "know" is correct but is slower. In some cases you
only want to
allow the second to be used. ] Data integrity is primarily the use of
information theory
to validate data, and user integrity is largely a managerial problem :-)
As justification for my pedantry, I'd like to refer people the effort
currently being
expended to develop and deploy firewalls and companies and universities all
around the world --- standard systems are not secure enough.
regards,
JonT
Disclaimers:
I am a postgraduate stduent on a scholarship, not an employee of
Microsoft ...
Received on Mon Dec 12 15:52:38 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT