Reflection Control in Izou

[jundl77]

Problem: How do you grant reflection rights selectively so that addOn's cannot reflect on certain parts of Izou.

So I found something very interesting in sun.Reflect.Reflection (yes sun package I know):

static {
    Map<Class,String[]> map = new HashMap<Class,String[]>();
    map.put(Reflection.class, new String[] {"fieldFilterMap", "methodFilterMap"});
    map.put(System.class, new String[] {"security"});
    fieldFilterMap = map;

    methodFilterMap = new HashMap<Class,String[]>();
}

This code creates two maps which include methods and fields that cannot be reflected upon, matched to their class. So for example, the security field in the system class cannot be reflected upon here. (The field includes the security manager)

If we replace this piece of code with code that includes all the methods and fields we want to block in Izou, then all problems should be solved. Do you think we can do this with the byte code injection thing? Otherwise I have another idea, too, but it's dirtier.

Idea No. 2: So it is pretty easy to deny reflection based on what method is called, so we could just filter out all "risky" methods manually, but that is not the case for variables. So somehow we need to remove all variables that store "risky" information and encapsulate them in methods or something. I don't know, but either way it seems very dirty, the top method actually could work nicely.

PS: SO link: http://stackoverflow.com/questions/17796815/protecting-fields-from-reflection-the-strange-case-of-the-system-security

[LeanderK]

Do you have a test to just try some ideas?

[LeanderK]

i think there's a third option

[jundl77]

Well I have the test in the debug addOn, but I don't know how to inject byte code with the class loader, so I can't try that, otherwise I would've tested, but can you give me a link to something that explains how to inject the byte code?

[jundl77]

Or we could just replace the class straight up in the class loader

[jundl77]

And did you have something in mind for a third option?

[LeanderK]

I injecting byte code in sun.Reflect.Reflection will not work....if you mean aspectJ. Even the javax package was a corner case and i had to be careful.

[LeanderK]

i meant test for messing around...some unit test to prototype? How did you test it?

[jundl77]

I do mean aspectJ, and well I didn't test it, it was more of a hypothesis

[jundl77]

Well hmm, lets see, maybe I can just load another class straight up when the class is loaded

[jundl77]

I think it is done! So reflection is blocked now in 2 ways:

1. If a class loaded from the IzouPluginClassLoader is trying to access the security or the addon package, access is blocked unless it is a secure access (This is still an issue for SDKs - I am not sure how to securely distinguish between an SDK and an addOn, since an addOn could just name itself after an SDK and then get access, so I blocked all classes loaded from the IzouPluginClassLoader for now).
2. If a class loaded from IzouPluginClassLoader is in the same stack as a class belonging to a reflection package, access is denied.

This seems to work so far! :)

[LeanderK]

The SDK does not need Reflection-Permission

[jundl77]

Yes, but it might need access to the secuirty/addon package in izou, which it is getting right now, but its unsecure

[jundl77]

exactly because an addOn could just include an sdk id in its own id

[LeanderK]

The SDK does not need to access the security-package/addon package per reflection. if this would be the case, something went terribly wrong.

[LeanderK]

The so link is very interesting....maybe we use this to "hack" us our own solution for a more fain-grained access control

[jundl77]

no I mean all kinds of access for the sdk in the security/addon package

[jundl77]

Yes but I've read some stuff and done some testing, I am not how accessible that class is, we could do the same by replacing the java Class.class to (that is where getDeclaredBlaBlaBla is). However you are not supposed to hack it that way I think.. haha

[LeanderK]

what do you mean with you answer? is this a reply to my first or second post? If it is a reply to the first...you are currently only blocking reflection access...or am i wrong?

[LeanderK]

(you forgot to add Identification/IdentificationManager to the reflection list....otherwise the security would be mostly useless ;) since you could fake being another add-on)

[jundl77]

ah well let me do that, but no I denied all access to the security and the addon package, not only reflection based but ALL access

[LeanderK]

ok, i mean you can't access anything beside the IdentificationManager & Context without reflection anyway.

[LeanderK]

ok i have an idea to give addons more fine-grained access.....I'm glad we have the SDK, because it will require moving classes to different packages. (but i don't think it will be any visible). The idea: We can create a separate package called org.izou.internal where all the Managers etc are placed and let the Interfaces stay at their current place. (IdentificationManager has to change, but this is not a major change....). Since Reflection-API is based on the class-object and we have full control over the classloaders we can prohibit them from loading any class inside this package -> they are not able to "see" them and use reflection on them.

[jundl77]

So you mean deny everything that is not in izou access to the internal package? (including sdk?) I actually had a similar idea. But then the SDK would still need access to the manager classes right? Unless we have a second set of interfaces.. Honestly, fine grained access should be pretty easy to give now. The real problem is securely distinguishing between an SDK and an addOn. In other words how do we make sure an addOn cannot fake itself to look like an SDK? I was thinking jar signing? But we don't have jars.. Can you our sign zip files too?

[jundl77]

If you got time, let me know, we could skype

[LeanderK]

since this is more a discussion -> https://gitter.im/intellimate

[jundl77]

I can't access it, it says I'm not part of the private group -_-, how do I log in?

[LeanderK]

just with github

[jundl77]

ready to merge the internal package branch? Or do you have something else to add