This discussion is archived
7 Replies Latest reply: May 24, 2010 5:54 PM by jtahlborn RSS

Role based reflection security manager?

843798 Newbie
Currently Being Moderated
Hi,

I am trying to find out whether there is a possibility to implement a role based Security Manager to control access to reflection operations (such as checkMemberAccess() for example).

I need to implement an application where using reflection is totally forbidden, except for some very specific parts of the code. Is this possible? If yes, how should I proceed? Is there a concept of identity around the security manager? Should I use ReflectPermission? If yes how?

I have been doing some reading, but it is still not clear to me. I am looking for a general implementation procedure.

Thanks.
  • 1. Re: Role based reflection security manager?
    jtahlborn Expert
    Currently Being Moderated
    yes, you can restrict only certain code to have reflective access, ReflectPermission("suppressAccessChecks") being the permission you would use. the code which is allowed to do the reflective access would be in a separate codebase, to which you would grant this permission using a policy file.

    one note, however: this does not work as any sort of DRM protection. if you are trying to build an application that other people can install and use locally, there is nothing you can stop them from doing with your code. java permissions are only useful to you if you are running the code yourself, and you want to protect your code/computer from other third-party code that you are using.
  • 2. Re: Role based reflection security manager?
    843798 Newbie
    Currently Being Moderated
    Thanks for the insight.

    I am not trying to implement DRM, but I want to install my application on end user's PC. Let me explain a little more about my issue:

    i) I have API interfaces and abstract classes. At runtime, I dynamically select a corresponding implementation (eventually via a full qualified name in a System property) and use reflection to instantiate the implementing class.

    ii) Now, some API manipulate sensitive information. I would not want someone to "substitute" its implementation to steal that sensitive information.

    From what you say, does it mean that if I restrict access to reflection (and system properties), users can still bypass any security mechanism and perform reflection? Or, is there a way to prevent this by using CodeSource and SecuredClassLoaders objects for example? Should I spend time investigating and learning about this or is it a dead end?

    Thanks.
  • 3. Re: Role based reflection security manager?
    jtahlborn Expert
    Currently Being Moderated
    Jrm wrote:
    Thanks for the insight.

    I am not trying to implement DRM, but I want to install my application on end user's PC. Let me explain a little more about my issue:

    i) I have API interfaces and abstract classes. At runtime, I dynamically select a corresponding implementation (eventually via a full qualified name in a System property) and use reflection to instantiate the implementing class.

    ii) Now, some API manipulate sensitive information. I would not want someone to "substitute" its implementation to steal that sensitive information.

    From what you say, does it mean that if I restrict access to reflection (and system properties), users can still bypass any security mechanism and perform reflection? Or, is there a way to prevent this by using CodeSource and SecuredClassLoaders objects for example? Should I spend time investigating and learning about this or is it a dead end?
    this is a dead end. this is exactly DRM. the idea behind DRM is that you want to give someone a locked box as well as the keys to open the box, but you want to restrict how and when the open the box. you are trying to run a program (the key to the locked box) on a user's computer that works with sensitive data (the locked box), but you only want your code to be able to open the box (DRM).

    the essence of you problem is this. you can put all kinds of security in your program, deliver it to me, and i can strip all that security right back out and run it. using java (or some other interpreted language) makes this even easier than normal, but it's still essentially possible no matter what language you use. if you have data which needs to be protected, then the only way to protect is to not put it on the user's box (e.g. run the code on your computer only).
  • 4. Re: Role based reflection security manager?
    843798 Newbie
    Currently Being Moderated
    Ok, fair enough regarding storing data on end user PC.

    But I see a contradiction here (or I mis-read you). I understand that SecurityManagers are used for applets to restrict some of their actions. What if people are able to bypass SecurityManagers? What is the point of having them? If a .jar application is started with a SecurityManager, can an end user strip it and replace it with its own security manager (from its own code for example)?

    I would be happy if I could deliver a .jar application with my customized and 'unremovable' SecurityManager. Is that possible or can one always fiddle the .jar to remove it?

    Because if people can always remove it, it is a permanent open door for man-in-the-middle attacks when code is delivered to end-users, correct? Is there any way to protect .jar from tampering?

    Thanks.
  • 5. Re: Role based reflection security manager?
    jtahlborn Expert
    Currently Being Moderated
    Jrm wrote:
    Ok, fair enough regarding storing data on end user PC.

    But I see a contradiction here (or I mis-read you). I understand that SecurityManagers are used for applets to restrict some of their actions. What if people are able to bypass SecurityManagers? What is the point of having them? If a .jar application is started with a SecurityManager, can an end user strip it and replace it with its own security manager (from its own code for example)?
    First of all, the SecurityManager is provided by the local computer, not the applet. But, the most important point is that the SecurityManager used when running third-party applet code is not trying to protect the third-party code, it is trying to protect the local computer from unknown third-party code. the user is perfectly able to disable the SecurityManager and/or give the third-party code whatever permissions it desires if they decide to trust the code. you are trying to protect your code (+which is the third-party code with respect to the user+) from the user. that is the opposite situation, and does not work.
    I would be happy if I could deliver a .jar application with my customized and 'unremovable' SecurityManager. Is that possible or can one always fiddle the .jar to remove it?

    Because if people can always remove it, it is a permanent open door for man-in-the-middle attacks when code is delivered to end-users, correct? Is there any way to protect .jar from tampering?
    As i said in my previous post, there is no way to stop this. as a software developer, i'm sure you are aware that you can find "cracked" versions of any commercial software that you are interested in (if you know where to look). what makes you think that your java program is any more "secure" than those other programs?
  • 6. Re: Role based reflection security manager?
    843798 Newbie
    Currently Being Moderated
    I am exploring this issue, I am not assuming that my code would necessarily be more 'secured'. Just trying to learn something.

    The conclusion I make is:
    - The SecurityManager and any jar signing will reduce accidental use of undesirable code on anyone's PC, but won't prevent people with bad intention from proceeding with code tampering.
    - That's as much as I can hope and expect, and I should live with that.

    Thanks for your valuable input.
  • 7. Re: Role based reflection security manager?
    jtahlborn Expert
    Currently Being Moderated
    Jrm wrote:
    I am exploring this issue, I am not assuming that my code would necessarily be more 'secured'. Just trying to learn something.
    sorry, i think my comment sounded harsher than i meant it. what i meant to say, was that if you think about how hard it is in general to stop (dedicated) people from manipulating programs to remove "unwanted bits", it should be fairly obvious that java programs will fare no better.
    The conclusion I make is:
    - The SecurityManager and any jar signing will reduce al use of undesirable code on anyone's PC, but won't prevent people with bad intention from proceeding with code tampering.
    exactly.
    - That's as much as I can hope and expect, and I should live with that.
    pretty much.

    that said, if you are only attempting to "keep the honest people honest", then hard coding the setup of a SecurityManager into the startup logic of your code will work fine. just be aware that anyone with a little bit of knowledge can fairly easily sidestep this "minor annoyance".