river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Oliver <fkoli...@gmail.com>
Subject Re: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
Date Mon, 16 Aug 2010 19:48:37 GMT
To at least partially answer my own question, I think that the answer
is that the socket can't be closed (at least in all cases).

If the delegate for a resource has multiple users (codebases,
principals, etc.) then closing the resource because permission for one
of the users has been revoked denies access to the resource by the
remaining valid users. (This allows a denial of service attack.) And
then, if you can't close the resource (socket), you can't kick loose
the no longer trusted thread blocked reading from it. You may be able
to determine the special case of no user retaining access (everyone's
access was revoked) and can then close the resource.

In the standard security model, there are no checks for
reading/writing sockets. Allowing revocation means that checks must be
added for each individual read or write call on the socket streams. Is
that level of performance satisfactory?

> If there is untrusted code on a thread's stack, and if the thread
> called a delegate, and if the delegate is in the between ECM.begin()
> and ECM.end(), then the delegate's reaper will be called, and it can
> close the socket.
>
> If the revocation happened elsewhere (e.g. the untrusted code is not
> on any stack, or is occupied with some other task), how does the
> socket get closed?
>
> Fred

Mime
View raw message