river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <peter.firmst...@zeus.net.au>
Subject Re: Subtleties of JAAS in an internet djinn (was Distributed network security)
Date Sun, 08 Jul 2012 19:02:04 GMT
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

Google JMXSubjectDomainCombiner, according to the javadoc, it has the behavour I'm looking
for.  Looks like someone has solved this problem before.



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 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message