No, sorry, I was right the first time it definitely is a security problem, the
alternate method proposed still has too many pitfalls for the unwary,
developers are likely to make mistakes due to complexity, security needs to be
simpler. The current methods are brittle when used in a remote context.
If the proxy is on the call stack when Subject.doAs is called, it needs to have
AuthPermission("doAs"), if it isn't there it will miss out on being injected
with the Subjects Principals, but then it can't use the dynamic grant given
with Principals, so it has to be given a dynamic grant without the Principals.
But there is still a problem with being able to run as a Subject, a static
method cannot be used to avoid the AuthPermission("doAs") or it will allow any
code to run as a subject, requiring a developer to implement a workaround in
private object code as follows.
1. Get current context
2. Using a PrivilegedAction call Subject.doAsPrivileged with the retrieved
current context.
In addition, all local code must be signed and all policy grants to principals
include a codebase signer.
Google JMXSubjectDomainCombiner, according to the javadoc, it has the behavour
I'm looking for. Looks like someone has solved this problem before.
Regards,
Peter.
Peter Firmstone wrote:
>
> 3. In Jini security documentation I've seen on the web,
> Subject.doAsPrivileged is called with a null AccessControlContext
> executing the proxy, in doing so the proxy PD is no longer on the
> stack, however it isn't clear when the proxy ProtectionDomain will
> be added back onto the stack, will it be possible for an object to
> be deserialised in a privileged context? It's highly possible,
> because of delayed class loading.
This statement isn't correct, the inherited domains are still included
on the stack, which includes the proxy provided that
AccessController.doPrivileged method hasn't been called first. If the
proxy's PD is on the stack during the Subject.doAsPrivileged call, it
needs to have AuthPermission("doAsPrivileged"), which is undesirable.
The risk of deserialisation in a privileged context still exists
however, if a domain with minimal Privileges isn't on the stack during
deserialisation.
