capabilities / security (was Re: VSTa - First Impressions)

[Jonathon Tidswell (MS Research Fellow)]

----------
> 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 ...