[cdi-dev] [JBoss JIRA] (CDI-486) Define security constraints for using CDI SPI

[Mohan Radhakrishnan]

Hi,
        This JEP(http://openjdk.java.net/jeps/176) proposes a new way of
enforcing the security permissions. Does this mean that the SPI methods
will be annotated with @ CallerSensitive

How does one update the issues list with these types of queries assuming it
is valid ? I am still learning the ropes.

Thanks,
Mohan

On Thu, Oct 2, 2014 at 12:44 PM, Jozef Hartinger (JIRA) <issues at jboss.org>
wrote:

>
>     [
> https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007947#comment-13007947
> ]
>
> Jozef Hartinger commented on CDI-486:
> -------------------------------------
>
> We should probably introduce a new permission and make it a requirement
> for calling BeanManagerMethod methods such as createInjectionTarget(),
> createProducer(), etc.
>
> > Define security constraints for using CDI SPI
> > ---------------------------------------------
> >
> >                 Key: CDI-486
> >                 URL: https://issues.jboss.org/browse/CDI-486
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >    Affects Versions: 1.2.Final
> >            Reporter: Jozef Hartinger
> >             Fix For: 2.0 (discussion)
> >
> >
> > Currently, the specification does not require any security checks to be
> performed when CDI SPI is used. It is not clear how this should be
> implemented.
> > Note that since a CDI implementation is required to support bypassing
> platform securiy checks (e.g. when invoking aprivate observer method),
> total absence of security checks on CDI SPI level could result in privilege
> escalation. Here's an example:
> > Suppose the application server bundles a sensitive method:
> > {code:JAVA}
> > public class ApplicationServer {
> >     static boolean explode() {
> >         // ...
> >     }
> > }
> > {code}
> > The method is package-private and thus cannot be by an application. If
> the application would be to invoke this method using reflection, it would
> need to first obtain the Method handle for the explode method. Obtaining a
> Method handle requires the "accessDeclaredMembers" runtime permission which
> the application does not have. It can however use the CDI SPI:
> > {code:JAVA}
> > Method method = null;
> > for (AnnotatedMethod<?> annotatedMethod :
> manager.createAnnotatedType(ApplicationServer.class).getMethods()) {
> >     if (annotatedMethod.getJavaMember().equals("explode")) {
> >         method = annotatedMethod.getJavaMember();
> >         break;
> >     }
> > }
> > {code}
> > Now the application has the Method handle without having the
> "accessDeclaredMembers" permission.
> > The application still cannot invoke the method as it needs to bypass
> security checks on access to the method first. This cannot be done without
> the "suppressAccessChecks" runtime permission.
> > Again, remember that CDI implementations are supposed to be capable of
> invoking inaccessible methods and this capability is exposed through the
> SPI. Therefore, the application call:
> > {code:JAVA}
> > Producer<?> producer = manager.getProducerFactory(annotatedMethod,
> null).createProducer(null);
> > {code}
> > Now, calling producer.produce() will cause the sensitive method to be
> invoked even though the application was not granted "accessDeclaredMembers"
> neither "suppressAccessChecks" permission.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.1#6329)
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141004/6b377e77/attachment-0001.html