[cap-talk] Semantics : is this a capability system & am I using the right semantics? (fwd)

[Rob Meijer]

On Tue, 12 Apr 2005, Jed at Webstart wrote:

> <Did the above comment by Rob go to the list?  I didn't see it.>

I seem to have send it to have been replying to the list with the wrong
mail adres. Ill send my last two posts again:


On Tue, 12 Apr 2005, David Hopwood wrote:

> Rob Meijer wrote:
> > I am working on a simple authorization system with tight cooperation
> > possibilities for incident response systems, and have been borrowing
> > many concepts form different ways of working with authorizations.
> > The only thing is that I combine and use these concept rather different.
> > Being afraid I may be misuse the naming, I have one important question:
> > 'am I using the right semantics?'
>
> Well, it's not a pure capability system. What security properties are
> you trying to establish by use of the 'lefts', 'objectgroups', 'lrs'
> and 'roles'? What advantages do they have to compensate for their
> complexity overhead?

I am trying to combine state for both basic user based user chosen role's
and state from an incident response point of view, with the later being
the more important one, and with context (the location in the chain).

I use role's for their re-usability, as re-usable container for an
unambiguous set of rights for statefuls that are within a state that
refers this single role. I have considdered dropping the 'objectgroup's,
and having the stateful have multiple roles at the same time, but thought
that:
a) Combining rights from different roles may lead to ambiguity
b) Having the rights point at state independant objects, rather
   than at roles would lead to more intuitive and more compact
   configurations.

The use of both rights and lefts was done in order to allow the state of
any of the objects in the chain to stop the action from being authorized.
This to be able to both say something like:

* a "niceuser" has a 'right' for FETCH and REPLACE actions
* a "nastyuser" has a 'right' FETCH actions only

but also:

* a "trustedfile" has a 'left' for FETCH and REPLACE actions.
* a "compromizedfile" has a 'left' for REPLACE actions only.

If you had only rights, or only lefts(ACL type rights), you
would only have one of them, the 'rl' is just a generalisation of
both rights and lefts.

> I'd be seriously concerned about whether this system is simple enough
> for programmers/designers to have a clear grasp of what operations will
> be allowed.

I partialy share this concern, but mostly with respect to the initial use
and configuration. One important choiche I had to make is to allow
'small' configurations to be rather big, in order for big configurations
to not become much bigger. This was actualy one of my main design goals.
Let me try to give an example of a rather big 'small' example, that should
be easy to extrapolate to a 'not so much bigger' biger setup.

Lets say we have a user 'TED' who used some tool 'readclient' that
communicates with a server 'dataserver' to 'FETCH' a file '~TED/DATA'.
For this situation a part of the configuration could be the folowing:

* TED is member of the objectgroups: 'basicuser' and 'anyuser' and can
  assume the roles: 'niceuser' and 'nastyuser'.
* readclient is member of the objectgroup: 'localtools' and can assume
  the roles: 'validtool' and 'trojanizedtool'
* dataserver is member of the objectgroups: 'localservers' and  can asume
  the roles: 'saveserver', 'vulnerableserver' and 'compromizedserver'
* ~TED/DATA is member of the objectgroups: 'localfiles','nonsystemfiles'
   and 'anyfile' and can asume the roles 'trustedtedfile',
  'untrustedtedfile' and 'compromizedtedfile'.
* The event FETCH is member of the objectgroups: 'readactions',
  'fsactions' and 'unprivaction'

If we now just look at a set of rights and lefts that would be neded for
the described action to be authorized if all 4 stateful objects were in
their most trusted state, we could see the folowing:

TED:
niceuser->context[L,0]:
	Right : readactions	localfiles
                fsactions	localserver
		unprivaction	localtools

readclient:
validtool->context[L,1]
	Right :	FETCH		dataserver
		FETCH		nonsystemfiles
validtool->context[R,2]
	Left  :	FETCH		anyuser

dataserver:
saveserver->context[L,2]
	Right :	fsaction	anyfile
saveserver->context[R,1]
	Left :	fsactions	basicusers
		readactions	readclient

~TED/DATA
trustedtedfile->context[R,0]
	Left :	fsaction	TED
		fsaction	localtools
		fsaction	dataserver

With this configuration for these states, the TRACS
system would thus be able to give out a capability for
this chain of statefuls and this event that will remain
valid for a set period, or untill the state of one of the
statefuls changes. The readclient will most likely be the
requester of the capability, that will used it to show its
authorization to the dataserver, that would ask the TRACS
system to validate it. This validation will consist of checking
if the state of any of the statefuls has changed only.

As you can hopefully see, this means as I said that setting up a small
configuration will result in a large config database, while a large
configuration will not be that much bigger. I hope you also agree that
it is not as much the complexity (I think its quite intuitive), but
the size of small configurations that could become a problem.
The main reason for posing my question however has also to do with
complexity, if I use the wrong or anti-intuitive semantics, than these
may add to the complexity.

Rob.