Hi Andreas,

On 23 June 2010 10:36, Andreas Maunz <andreas at maunz.de> wrote:

[....]

> 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.

Yes, however initiating such recovery of deleted files would require
either elevated (root) privileges or physical access to the hard disk,
holding the file system, while in our OT case "taking over" by an
attacker would require only:

1) valid (unprivileged) user/pass and corresponding token;
2) knowledge of the (temporarily unprotected) resource URI (the
resource URI is public info, the fact that it is temporarily
unprotected can be discovered by sending a crafted list of consecutive
queries);
3) a sufficiently long window of opportunity (policy is dropped, but
the resource takes a while to disappear, e.g. in case that the request
for resource deletion is lost or fails for some reason).

I understand that currently we don't have a complete solution for this
scenario in mind, however we could still try to mitigate it as much as
possible, e.g. by:

-- introduce a rate limit for consecutive queries by a given user
(especially for excessive repetitive queries, checking the policy of a
given protected resource);
-- try to make the "window of opportunity" as small as possible (e.g.
when a policy is about to be deleted, first check that the web
service, holding the corresponding resource, is available and ready to
delete the resource -- I even imagine some "pseudo" delete operation,
which would simulate a delete of the policy and the resource and only
when it succeeds, the policy is effectively deleted, immediately
followed by the resource);

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

Kind regards,
Vedrin