[cap-talk] RE: [eros-arch] This might be a bit off-topic!

[Karp, Alan]

I don't think that using capabilities to solve real world security problems is off topic at all.  However, there is another list, cap-talk, that might be a better forum for this discussion.  The two lists have many of the same subscribers, but the overlap isn't perfect.  I've taken the liberty of copying that list.  When replying to these lists, we prefer not to include the entirety of the orginal note.  However, I'm breaking that rule here so that everyone on cap-talk can see what you propose to do.
 
While I like the general thrust of your proposal, I have a couple of concerns.  The most serious is your remark
 
> 
> A TRACS capability is not the purist atomic version of the 
> capability, in
> TRACS a capability is defined as a group of tasks that can be 
> performed on
> a group of subjects.
> 
 
One of the benefits of capabilities is that they combine designation with authorization.  There is no possibility of using the wrong authority.  The best description of the problem is Norm Hardy's "Confused Deputy" paper available at 
 
   http://www.skyhunter.com/marcs/capabilityIntro/confudep.html
 
What you propose sounds like what people on this list refer to as an ambient authority system.  I make a request, and the system checks my environment to see if I have the requested permission.  It's too easy to be confused.  One of the advantages of capabilities is that all requests carry the exact set of authorities to be used.
 
My second concern is related to role changes.  You state
> 
> In a TRACS, role changes are done according to a state 
> machine definition
> of the Actor, triggered by events. These events may be Actor generated
> statechange requests, and, verry important for security, 
> (Actor triggered)
> state change requests may require their own authorisation. For this
> purpose TRACS aims to use a modular system for Actor event 
> authorisation
> meganisms, hopefully excisting frameworks can be used for 
> this purpose.
> The security of role-changes is not fully determined by the 
> actor state
> machine. The Role itself may have so called 
> Role-Entry-Prerequisites, that
> define their own authorisation prerequisites. Again use of excisting
> authorisation frameworks will hopefully also be usable here.
>
 
I don't know what you mean by "existing authorization frameworks", but I don't know of any that meet your needs.  These frameworks allow the subject to change roles, but they don't allow the subject's role to be changed without compliance by the subject.  Additionally, all the systems I've seen are based on ACLs, not capabilities.
 
E-speak (info available from my web site http://www.hpl.hp.com/personal/Alan_Karp) did provide such mechanisms.  E-speak (open source GPL, LGPL) was designed as a scalable distributed system that allowed cooperation across trust boundaries.  It included several interesting features, including a novel naming system, a new form of capabilities that included negative permissions, and a capability controlled event system.  In e-speak, all communications was interpreted through a client's protection domain.  Someone with the right capabilities could modify this protection domain or even switch which protection domain a client used.  I think this mechanism may be closer to what you need than more commonly known RBAC systems.

Another factor that you need to consider is the complexity of following the rules in a dynamic environment in which subjects are frequently changing roles.  It is very hard for well-meaning subjects to avoid violating the rules in such a system.  While you can't prevent a subject from misusing a valid authority, a subject that wants to obey the rules will need some help.  E-speak introduced some mechanisms that support what we now call Voluntary Oblivious Compliance (VOC).  Basically, if you ask me for a file, I don't send you a bag of bits because I don't know if the rules allow you access.  Instead, I send you a handle to the file, and the system will allow you access to the file only if you're allowed to see it.  E-speak used negative permissions to implement VOC, but Mark Miller has figured out how to incorporate VOC into object capabilities.  He calls it the Loan Officer Protocol (you can borrow this money if you can prove that you don't need it).  The capability is tran
 sferred only if the recipient already holds it.

One other, less significant, point is your concern with subjects, objects, and resources.  E-speak treated everything as a resource.  A file was a resource, the file system was a resource, the user was a resource.  This uniformity greatly simplified the design and led us to think about things in different, but useful, ways.  Whether you're a subject or an object changes from moment to moment.  When a process requests a file, it's the subject and the file system is the object.  In a well designed system, the reply will treat the requesting process as the object and the file system as the subject.  Similarly, the user is never in the computer, and you can get into trouble if you're careless about this point.  People interact with the system through a process called the user agent that has all the person's rights.  This process is just as much a subject or object as any other component of the system.
 
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
 
 
> -----Original Message-----
> From: eros-arch-bounces at mail.eros-os.org 
> [mailto:eros-arch-bounces at mail.eros-os.org] On Behalf Of Rob J Meijer
> Sent: Friday, October 01, 2004 6:31 AM
> To: eros-arch at mail.eros-os.org
> Subject: [eros-arch] This might be a bit off-topic!
> 
> 
> This might not be the best place to ask this question, and I 
> hope I'm not
> to much off-topick but I am at this point starting off a 
> project (that I
> need to do to fulfill an other more important project of a Security
> Incident Pollicy Enforcement System), A 'statefull' 
> authorisation system
> that does try to borrow a few concepts from different 
> authorisation and
> security systems in order to become a trivial but powerfull 
> and flexible
> authorisation system usable within my Security Incident 
> Pollicy Enforcement
> System project.
> 
> As I am absolutely no expert at capability based systems, 
> changes are that
> I may be misusing terms or misinterpreting basic capability 
> constructs.
> It might even be that what I am planning to build should not be labled
> as capability based, but should use some other more descriptive term.
> As I gather that a lot of capability people on this list, I would like
> to ask if you could be bothered to comment on these initial design
> scribles for the trivial authorisation system I wish to start building
> shortly.
> 
> Any coment on the whole concept of using state in the authorisation
> process, are also extremely welcome.
> 
> 
> T.I.A.
> 
> Rob J Meijer
> 
> ---------------------------------------------------------------------
> 
> Trivial Rolebased Authorisation & Capability Statemachine (TRACS)
> 
> This project is the first spin-off project of the Security 
> Incident Policy
> Enforcement System project. In the process of designing a 
> SIPES, the need
> was recognized for the implementation of an authorisation server that
> provides functionality not provided by any of the current 
> authorisation
> solutions. The introduction of state into the authorisation process is
> crucial for the future intergration of automated security incident
> response with authorisation processes as outlined in the 
> SIPES whitepaper.
> 
> Actors, Subjects, Tasks and Capabilities
> 
> The TRACS authentication system has as its basis a simplified 
> form of what
> is commonly known as a capability based system. In such a 
> system, if an
> Actor wishes to perform a Task on a Subject it is required to have a
> Capability that enables this.
> 
> Role's and State
> 
> In TRACS the capabilities are not owned by the Actor, they 
> are owned by
> something that we call a Role. In a Role-Based sytem, an 
> Actor can have
> multiple roles. In simple role based systems such as TRACS, 
> an Actor can
> assume only one role at any given time. In more advanced Role-Based
> systems a more complex inheritance based role-model exsists 
> that allows an
> Actor to virtualy have multiple roles at a single point in 
> time. There are
> also profile based systems that are marketed as Role-Based 
> systems, that
> only provide static capabilities to the actors. TRACS is a simple role
> based capability system with respect to the fact that an 
> Actor has only a
> single Role at any moment in time, one important extension to 
> this however
> is the fact that the Actor within the TRACS is provided with 
> his own so
> called State-Machine, and role changes made by the actor are 
> made by way
> of state changes trigered by events. These events will be 
> Actor-Triggered
> in the first version of TRACS, however ones the more of the 
> SIPES system
> is integrated, might also occur as a result of security incidents. The
> state machine limits the role transitions an Actor could make with the
> goal of added system security.
> 
> Users Processes and Subjects
> 
> Within TRACS a user is basicly viewed as an Actor (note that 
> in the case
> of system administration of the TRACS, a user could also be 
> the Subject).
> This Actor would in order to perform a specific task on a 
> Subject, make a
> request to some Process. This Process has now a dual 
> position, viewed from
> the user its a Subject, but viewed from the Subject it is 
> performing the
> task on its an Actor. In order for the task to be performable by the
> process, the TRACS needs to check for 3 seperate capabilities:
> 
>    1. The user himself needs the capability to perform the task on the
>       Subject.
>    2. The User needs to have the capability to ask the 
> Process to perform
>       the Task.
>    3. The process needs the capability to perform the task on 
> the Subject.
> 
> As shown by this, there are two types of Actors:
> 
>    1. Users
>    2. Processes
> 
> Subjects
> 
> The two base types of Subjects are Processes and Resources, there is
> however also seen from the view of TRACS administration (Note that as
> TRACS is a capability system, system administration of 
> different parts of
> the system itself is also based on capabilities, thus normal 
> users will in
> many cases be performing limited scale administration tasks 
> on the TRACS.
> The identifiable subject types in the TRACS are:
> 
>     * Resources (could be basicly anything outside of the 
> TRACS that uses
> the TRACS to authorize access).
>     * Actors (Processes and Users)
>     * Roles
>     * Capabilities
> 
> 
> A TRACS Capability
> 
> A TRACS capability is not the purist atomic version of the 
> capability, in
> TRACS a capability is defined as a group of tasks that can be 
> performed on
> a group of subjects.
> 
> Role (State) changes of an Actor
> 
> In a TRACS, role changes are done according to a state 
> machine definition
> of the Actor, triggered by events. These events may be Actor generated
> statechange requests, and, verry important for security, 
> (Actor triggered)
> state change requests may require their own authorisation. For this
> purpose TRACS aims to use a modular system for Actor event 
> authorisation
> meganisms, hopefully excisting frameworks can be used for 
> this purpose.
> The security of role-changes is not fully determined by the 
> actor state
> machine. The Role itself may have so called 
> Role-Entry-Prerequisites, that
> define their own authorisation prerequisites. Again use of excisting
> authorisation frameworks will hopefully also be usable here.
> 
> Project Status
> 
> This project is currently my personal active part of the 
> SIPES project, it
> is in its conceptual design phase, but it currently receives my full
> (spare-time) attention. Anyone who wishes to give input on the abouve
> description of the system can currently still do so, I am 
> verry open to
> sugestions that may influence the design at this point in time. My
> deadline for the system specs is the first of december 2004, 
> when I want
> to start finalizing the system design and starting on implementation.
> Please take this deadline into considderation when sending me 
> feedback on
> what is described here. After November 27th 2004 I might no 
> longer process
> new incomming comments that could have architectural impact. 
> Thanks for
> any input rmeijer at xs4all.nl.
> ----------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> eros-arch mailing list
> eros-arch at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/eros-arch
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20041001/7c18dfd9/AlanHKarp.obj