[hibernate-dev] Fwd: [jsr-303-eg] [NEW] SecurityManager considerations

[Emmanuel Bernard]

Begin forwarded message:

> From: Emmanuel Bernard <emmanuel.bernard at jboss.com>
> Date:  August 4, 2009 16:26:57  EDT
> To: jsr-303-eg at jcp.org
> Subject: Re: [jsr-303-eg] [NEW] SecurityManager considerations
> Reply-To: jsr-303-eg at jcp.org
>
>
> On  Aug 4, 2009, at 12:57, Ed Burns wrote:
>
>>>>>>> On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns  
>>>>>>> <Ed.Burns at Sun.COM> said:
>>
>>>>>>> On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard <emmanuel.bernard at jboss.com 
>>>>>>> > said:
>> EB> Is there other specs enforcing that. I know JPA does not, I am
>> EB> wondering if other pluggable EE specs enforce such calls.
>>
>> EB> I'll ask around and report back.
>>
>> EB> Other question, what's the perf cost?
>>
>> EB> At the same time as discussing runtime performance cost, we  
>> also need to
>> EB> agree on how strongly we want to require it.  My original wording
>> EB> started with, "If the implementation is intended to run in a  
>> container
>> EB> with the SecurityManager enabled..." meaning that compliance is
>> EB> optional.  I think we should stick with that level of compliance.
>>
>> EB> As for runtime performance, I'll ask our expert but I think the  
>> general
>> EB> practice is to use the doPrivledeged() versions only if  
>> actually running
>> EB> with SecurityManager enabled.
>>
>> Here's what Ron Monzillo had to say when asked this question.
>>
>>>>>>> On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo <Ronald.Monzillo at Sun.COM 
>>>>>>> > said:
>>
>> RM> Ed, as I said, he should only wrap those apis, that having done  
>> so,
>> RM> woould not be such that they would then provided their callers  
>> with an
>> RM> opportunity to exploit the java security model. Iow, he doesn't  
>> want his
>> RM> api to be the manifestation of a capability that can be used by  
>> its
>> RM> callers to do things that they would otherwise be prevented (by  
>> the
>> RM> security managr from doing) from doing.
>>
>> RM> within that context, which I admit is pretty high level,  the  
>> answer to
>> RM> his question afaik, is no, in other words I don't know of any  
>> places
>> RM> where we have mandated such encapsulation... but you can turn the
>> RM> question around, or at least reinforce what you have already  
>> said,
>> RM> perhaps by saying (somthing like)
>>
>> RM> if he doesn't do the encapsulation within his api, he is in  
>> establishing
>> RM> a requirement that the java protection model be disabled for any
>> RM> application that needs to call his api; which as you hav noted
>> RM> substantially limits the potential utility of running with a  
>> security
>> RM> manager enabled.
>>
>> Please let me know if you need more information.
>
> Here is my analysis.
> The RI does need to priviledge the following calls:
> - Thread.getContextClassLoader()
> - Class.getClassLoader()
> - Class.getMethods()
> - Class.newInstance()
> - Class.getMethod(String)
> - Class.getConstructor()
> - Class.getDeclaredFields()
> - Class.getDeclaredMethods()
> - Class.getDeclaredField(String) / getDeclaredMethod(String)
> - AccessibleObject.setAccessible
>
> The RI might need to priviledge the following calls:
> - method.invoke
> - Field.get
>
> Now here are the gotchas.
> Bean Validation does expose some of the result of these methods  
> (indirectly).
> - ConstraintViolation.getInvalidValue does expose the value and a  
> few of the priviledged info (property path, leafBean etc)
> - the metadata API does expose property names (and their return  
> type): there are the names of potentially non public field or getters
>
> Do we consider the exposition of these extra info as breaking the  
> doPriviledge contract. As Ron was saying we are giving away some  
> information that a non privileged code could not have access to  
> otherwise.
>
> So we have two choices, consider that if the user does not have  
> access to these priviledges, we fail as well (the current impl).
> Make use of our priviledged position but be aware of the leaks we  
> enable.
> WDYallThink?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090804/3146d60f/attachment.html