Hi again,

On 23 June 2010 11:34, Vedrin Jeliazkov <vedrin.jeliazkov at gmail.com> wrote:

> Perhaps there are more elegant ways to deal with this issue -- any other ideas?

Another interesting feature would be to store a full archive of all
policies that have existed at any given time, allowing some user with
elevated privileges to follow and analyse the evolution of policies
for a given resource. In particular, cases when the ownership of a
given resource has changed or permissions for this resource have
become less strict could be highlighted, enabling easier
identification of possible security breaches. We would need to define
what "less strict" means -- here's a first attempt:

1) no access;
2) only read access only for owner of resource;
3) only read access only for owner and group-owner of resource;
4) read&write access for owner of resource;
5) read&write access for owner and group-owner of resource;
6) read access for everyone;
7) read&write access for everyone;

There could be a few more cases to be listed, but you get the idea.
Any transition to a higher entry in this list should trigger some
highlight when analysing the policy archive.

In fact, I'm not sure whether we have the notion of group-owner
currently? If we don't have it (e.g. we only have group permissions,
not ownership), then the list might look in a slightly different way,
but still we should be able to highlight cases when more (or
different) users get (possibly broader) access to a given resource.

Another thing that comes to my mind is whether we're able to
distinguish self-elevating of privileges from other cases. I mean, it
might be handy to know whether a request to the policy service would
result in elevation of the privileges of the issuer of the request or
it would only change the privileges of a different user for the
resource, owned by the issuer. Both can be legitimate requests,
however the former is perhaps somehow riskier from security point of
view, than the later. I think that the former should practically occur
mainly during resource creation (and perhaps only then).

Last but not least, you mentioned that permissions and ownership are
handled separately. Does it make sens to hold ownership information a
bit longer and delete it only when the resource is effectively
removed? I mean, something like this:

1) user requests resource deletion;
2) AA checks that user is entitled for this operation;
3) permissions for the resource are removed;
4) resource is removed;
5) ownership information is removed.

The rationale is that in a situation when the resource takes a while
to disappear, the system would know who was the owner of this stale
resource and could disallow other users to create policies with
different permissions for this resource, thus probably solving the
issue under discussion.

Kind regards,
Vedrin