-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reflection Control in Izou #42
Comments
Do you have a test to just try some ideas? |
i think there's a third option |
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? |
Or we could just replace the class straight up in the class loader |
And did you have something in mind for a third option? |
I injecting byte code in sun.Reflect.Reflection will not work....if you mean aspectJ. |
i meant test for messing around...some unit test to prototype? How did you test it? |
I do mean aspectJ, and well I didn't test it, it was more of a hypothesis |
Well hmm, lets see, maybe I can just load another class straight up when the class is loaded |
I think it is done! So reflection is blocked now in 2 ways:
This seems to work so far! :) |
The SDK does not need Reflection-Permission |
Yes, but it might need access to the secuirty/addon package in izou, which it is getting right now, but its unsecure |
exactly because an addOn could just include an sdk id in its own id |
The SDK does not need to access the security-package/addon package per reflection. if this would be the case, something went terribly wrong. |
The so link is very interesting....maybe we use this to "hack" us our own solution for a more fain-grained access control |
no I mean all kinds of access for the sdk in the security/addon package |
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 |
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? |
(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) |
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 |
ok, i mean you can't access anything beside the IdentificationManager & Context without reflection anyway. |
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). |
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? |
If you got time, let me know, we could skype |
since this is more a discussion -> https://gitter.im/intellimate |
I can't access it, it says I'm not part of the private group -_-, how do I log in? |
just with github |
ready to merge the internal package branch? Or do you have something else to add |
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):
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
The text was updated successfully, but these errors were encountered: