Hi Vedrin, All,

Vedrin Jeliazkov wrote on 06/22/2010 03:54 PM:
> OK, I agree that reversing the order of the operations might be a
> sensible approach, provided that the resource is not accessible when
> no policy exists for this resource.

Without a rule matching a specific URI, access to this URI is denied 
completely.

> That is to say:
>
> -- Create: (1) resource, (2) policy;
> -- Delete: (1) policy, (2) resource;
>
> However, there are some issues that need further clarification in this
> case as well:
>
> 1) At creation time, when no policy exists for a given resource and
> nobody has access to this resource, how is the resource owner
> differentiated, in order to allow him to create the corresponding
> policy? It sounds like the ownership should be recorded elsewhere, not
> in the policy itself? Or perhaps you meant inverting the order only at
> deletion time?

Yes, ownership is recorded seperately. When the resource is created, 
nobody will have access to it at first.
However, anybody (any registered OT user) can register a policy for it, 
which is a security issue.
This is also currently possible, regardless whether such a resource exists.
However, I could implement to check access to a resource upon upload of 
the policy file, which would effectively prohibit registering resources 
that do not exist. SSO should be able to receive a 401 (Unauthorized) 
instead of 404 (Resource not found) in this case.

> 2) When deletion is initiated and a given policy is removed, but the
> associated (un)protected resource still exists for some time, what
> would prevent a different user (not resource's owner) from creating
> another policy for the same resource?

Nothing. It is possible for any registered OT user to register an 
arbitrary number of policies associated with any currently unprotected 
resources. This is a security issue.
However, once a policy is registered for a given resource, only the 
owner of a resource (= the first OT user who registered a policy 
associated with it) can register other policies associated with that 
same resource at a later point.
We could also think about a mechanism for transferring ownership to 
another user.
You can find out who is the owner for a given resource (see the script I 
sent around yesterday).

> 3) Orphan (both resource and policy) prevention is still an issue,
> regardless of the order of creation/deletion of policies and
> resources. IMHO we need to define the procedures which would ensure
> that (i) orphans would be highly unlikely to exist and if they do
> emerge, that would be only for short periods of time (ii) eventual
> orphans wouldn't survive for more than<some reasonable time interval
> (e.g. 2 hours)>

The latter would require some "garbage collection" mechanism, which the 
A&A service would have to implement to check for orphaned policies 
(Obviously, it cannot check for orphaned resources).
I imagine this quite difficult. In fact, I am not sure whether orphaned 
resources are a problem (see my file system analogy below).

> Going back to the (unix) filesystem abstraction, we come to the
> separate notions of permissions and ownership. I'm not sure whether
> these two concepts can be easily and transparently merged in a single
> policy. We might need to have separate means to describe ownership and
> access permissions. As an example, imagine that user "vedrin", owner
> of resource "test" declares that nobody (including himself) has access
> to "test". In this case, the possible deadlock is avoided by the
> separate ownership mechanism, which allows him to override this
> restriction and access "test", since he is the owner of "test":
>
> - - - - - - - - 8<  - - - - - - - -
> vedrin at eos ~ $ touch test
> vedrin at eos ~ $ ls -al test
> -rw-r--r--  1 vedrin  vedrin  0 Jun 22 16:44 test
> vedrin at eos ~ $ chmod 000 test
> vedrin at eos ~ $ ls -al test
> ----------  1 vedrin  vedrin  0 Jun 22 16:44 test
> vedrin at eos ~ $ rm test
> override ---------  vedrin/vedrin for test? y
> vedrin at eos ~ $ ls -al test
> ls: test: No such file or directory
> - - - - - - - - 8<  - - - - - - - -
>
> It might be a sensible approach to think how to model this example in
> our distributed RESTful services case.

Ownership is already separated from policies, so the above file system 
analogy is possible:

resource URI ~ physical address of file on disk
SSO policy ~ file system (fs) table, including access rights
resource owner ~ file owner

In particular, the owner is able to delete a policy (~remove entry from 
the fs table), even if he does not have access to any resources (~files) 
associated with the policy.
Also, in file systems, the resource is normally not physically deleted 
from disk upon removal of the fs tab entry. This is equivalent to our 
scenario: the data might still be physically there, but not accessible.

To summarize:
- Currently, policies can be registered even if the resources do not 
exist (this could be fixed).
- Resources that exist but are not associated with a policy can be 
"taken over" by an attacker (currently no protection for that). However, 
an analogous issue also exists in file systems in the form of recovery 
of deleted files.

Kind regards
Andreas