[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rant on Capability Security [LONG]

Sorry for the delay in responding.  It has taken me some time to understand
your questions.  It seems our vocabularies are quite different.

At 3:10 AM -0700 4/18/97, Steen Larsen wrote:
>Hi Bill,
>
>here are some comments on your interesting thoughts.
>
>Bill Frantz wrote:
>>
>>[... deleted to save space ...]
>>
>> We can also control where programs can transfer the data they can access by
>> controlling their communication channels.  This technique is called
>> confinement. (See Butler Lampson's paper, "A Note on the Confinement
>> Problem", Communications of the ACM, V 16, N 10, October, 1973.
>> <http://www.cis.upenn.edu/~KeyKOS/Confinement.html> for a discussion of its
>> limitations.)  Systems which allow programs to write files in essentially
>> any directory can't confine those programs.
>Is this not the same as limiting its privilege? I mean if the
>communication
>channels are protected by an ACL then removing the privilege to access
>the
>channels will be the same as confinement.

Yes - But see the paper for an idea of the number of channels that are open
by default in common systems.
>
>[... deleted to save space ...]
>
>> A solution to the problem of programs running with all the user's authority
>> is to create a new security domain for the program instance, and give it
>> only the authority it needs to do its job.  Consider how we would do this
>> in an ACL system.  Assume Alice is executing program Foo.  We need to
>> create a new security domain, lets call it Alice'sFooInstance.  We need to
>> add Alice'sFooInstance to the ACLs for all the resources that the program
>> needs during its execution.  This solution lets us enforce the principle of
>> least privilege, but still leaves us exposed to the Confused Deputy Problem.
>Your terminology confuses me a bit here.
>
>Why do you use "authority" instead of privilege?

The simple answer is, it's the term I've been using for 25 years.

More importantly, in most systems (e.g. Unix and NT), program instances
have some default authorities (e.g. access to the current directory).
Those authorities are "normal".  Every instance has something like them.
Things beyond them are special "privileges".

Contrast that situation with systems such as KeyKOS, where a program
instance without authority can't do *anything*.  In KeyKOS, it requires
specific authority to access the machine code of the program and another
authority to consume CPU time.  There are no global defaults that every
program instance gets.  (KeyKOS goes further in this direction than many
other capability systems.)

I agree that the difference is subtle, but it is important.


>Too me a "security domain" is a set of systems under the same security
>administration.

Can you suggest a better term than security domain?


>Instead of security domain I would say that you propose
>to create a temporary principal/user and a temporary change to the ACLs.

Your understanding of what I mean is correct.


>(Btw. this could really screw up auditing)

It doesn't screw up auditing because creating this new entity along with
its access permissions, is an auditable event.  You will be able to trace
actual read or write accesses back to the human user, and the specific
program.  (Being able to trace back to the program will help locate Trojan
horses.)


>I wonder if it one couldn't obtain the same by fine tuning the
>privileges
>of the application.

Of course.  Capabilities are an implementation technique for performing
that fine tuning.  Of course, it is not the application or the user whose
privileges need to be fine tuned.  It is the combination of their
privileges which they have chosen to delegate to an instance of the running
application program which need to be fine tuned.
>
>> [... deleted to save space ... ]
>> One view of capabilities is as distributed ACLs.  Instead of keeping the
>> ACL next to the object it is protecting, we can distribute the entries, and
>> authenticate them by a digital signature.  A capability can be implemented
>> as an object pointer signed by the authority which grants access to that
>> object.  Since the Internet is inherently insecure, this implementation
>> would fall to the first packet sniffer.
>To me access control involves two objects:
>
>1) An object identifiying the privilege of a user. I think this is what
>you
>   would call the distributed ACL. Microsoft calls it a security
>descriptor,
>   ECMA calls it a privilege attribute certificate (PAC). I am not yet
>sure
>   if an SPKI certificate is an equivalent beast. But I think so.
>   This object is highly distributed and may be issued by a central
>   authorization (aka privilege) service.
>
>2) An object linked to the resource that we are trying to protect. This
>is
>   the famous Access Control List.
>
>These two objects are then compared by the access control facility to
>determine
>the kind of access that a user is granted.
>
>In an ideal system the administrator should be able to decide if he
>wants to
>put lots of information in the ACL or the PAC.
>
>Some examples:
>
>   NT like:
>
>	PAC: caller is member of groups: administrators, webmasters
>	ACL: grant full access to administrators, read to guests
>             Trust PAC issuer X
>
>or
>
>   "Empty ACL" / All access decisions delegated to "PAC issuer X"
>
>	PAC: caller has read access to ftp.securesite.com
>        ACL of ftp.securesite.com:
>             Trust PAC issuer X
>
>	(To me this pac looks like the certificates that has ben discussed
>         on this mailing list)

In this second case, the PAC is a capability.  Your example is the
ftp.securesite.com capability with whatever authority that grants.
(Presumably the ability to run ftp to/from ftp.securesite.com.)

>
>[... deleted to save space ...]
>
>If we want to make a really good system we should probably look at
>what others have tried before us. For some very interesting ideas on
>privileges, delegation protected by cryptographic means including how
>delegation can be limitid and confined to the least privilege, etc. I
>recommend to read "SESAME V4 - Overview". This can be found at
>
>	http://www.esat.kuleuven.ac.be/cosic/sesame.html

This URL gave me "Document contains no data" in Netscape 3.0.


>(These people have extended Kerberos with advanced authorization
>and public-key stuff)
>
>I also recommend the easy to read document "ECMA Technical Report 46"
>which is worth reading for is terminology and generic security archi-
>tecture. (To us this is a great framework for comparing security
>products. As you know the marketing departments has a great way of
>screwing up security terminology).
>ECMA reports are available for free (on-line and hard-copy) at
>
>	http://www.ecma.ch

I could not find a copy of the complete report online.  (The FTP site only
had a copy of the abstract.)  I sent them email asking for a postal mail
copy.


>
>
>Best regards
>
>Steen
>
>--
>
>Steen Koefoed Larsen
>
>SITA R&D Nice, France                | @ Home
>E-mail: steen.larsen@ed.nce.sita.int | NEW E-mail: steen@who.net
>Phone : +33 4 92.96.63.67            | GSM Mobile: +45 40512486
>Fax   : +33 4 92.96.64.92            | or (French) +33 6 09090568
>
>Disclaimer: This letter may reflect my personal opinion.
>
>      "Liberty lies in the rights of that person whose views
>       you find most odious"  - John Stuart Mill



-------------------------------------------------------------------------
Bill Frantz       | God could make the world   | Periwinkle -- Consulting
(408)356-8506     | in six days because he did | 16345 Englewood Ave.
frantz@netcom.com | not have an installed base.| Los Gatos, CA 95032, USA
References: