Roles and Rooms [was: re fwd re.. Encryption Opinion]

On Wed, Aug 27, 2014 at 4:07 PM, Bill Frantz <[email protected]> wrote:

> For capability-based systems, I think *the* hard problem is
> configurability:  How do you turn an access policy defined in human terms
> into a set of capabilities that accurately and completely implements the
> policy?  Given a set of capabilities, how do you turn it into something
> human beings can actually understand?


One approach I've used is role oriented - e.g. you have objects
representing different 'roles' a user might play, and each role has
associated with it a set of specific capabilities (each coupled with a
description, API, and a default HTML widget). The role objects may then be
attenuated per user. An administrator can manage separately the
capabilities associated with each role, and the roles assigned to each
user. This is basically ACLs, except with the mashability, delegability,
and extensibility of the object capability model.

Another approach I've pursued with a fair amount of early promise (though I
tabled it in 2010 to focus on my new programming model) is a multi-agent
concept based on a 'rooms and keys' metaphor. This is similar to
multi-agent blackboard systems / tuple spaces / etc.. Users and software
agents are given revocable keys to different rooms, and each room contains
in it a set of objects representing capabilities. All capabilities in a
room are attenuated and revocable at the whole-room scale, i.e. by later
denying access to that room. However, users aren't limited to taking
objects from a room; they can also add objects to a room, and thereby
publish services that may attenuate authorities obtained from more secure
rooms.

In general, I envisioned that a software service would supply a 'public'
room or API, which can be extended in rather ad-hoc ways. In addition,
objects in a room would be composable, i.e. having holes or types that can
be integrated with objects from other rooms (e.g. this is an almost
complete service, but you need to provide the persistence and display
capability).

I find that physical metaphors and multi-agent systems ideas are a very
good fit for making object capability systems comprehensible. Other ideas
worth exploring are 'Data Context Interaction' and 'Role Oriented
Programming'.

In a more general sense, Ka-Ping Yee's "User Interaction Design for Secure
Systems" [1] can be applied almost directly to development of user
interfaces in capability secure systems. Capabilities are very flexible,
but the design principles in this paper provide a little extra structure
and guidance to the whole configurability question.

[1] http://zesty.ca/pubs/csd-02-1184.pdf



The *implications* of security policies - what is *actually* granted or
> forbidden, not as a result of the explicit policies but as a result of what
> they imply - is something that's difficult or impossible to understand


I think that the idea of 'security policy' is difficult to understand in
general. When people hear 'security policy', they think about some sort of
great rulebook in the sky that will somehow enforce interactions. This is
the wrong way of thinking about it.

With an object model, it is not difficult to describe systems and games
that match our physical intuitions. Consider a capability-secure MUD or MOO
- you could enforce game rules directly at the level of quest objects, keys
and doors, and so on. The ability to 'listen' to a room could be a
revocable capability, granted only when your avatar stands within the room
or one of its neighbors.

Further, such intuitions apply also to interactions between users in a
multi-agent system. The main thing we need there is a little extra
awareness, visibility, trusted path, and more universal options for
revocation.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk