setting security manager
Hi,
I have a typical requirement which asks me to have a security manager which applies to only a part of the code and not to the whole code. I will try to explain it.
Lets say I have a class A which does something (may be it accesses files, open socket connections over network etc etc). This class A is a sort of trusted class and is allowed to do everything. Now suppose this class is built in such a manner that it can load another class B at runtime which could be any class written by any third party. So what exactly class B will do cannot be predicted because it is a third party class. Now what I want is to set a security manager only for class B that will prevent it to do any nasty things like accessing file system, shutting down vm etc. . Please note that class A can do all these things but class B should not be allowed to do these. If class B tries to do any of those things then security exception should be thrown.
Hope I made my point clear.
Please note that I am not talking of Applets but complete application so pls dont forward any replies which applies to applets.
Can anyone help pls........
regards.
[1169 byte] By [
crack_ita] at [2007-10-1 10:58:55]
Hi,grant your code ALLPermissions by specifying the codebase/signedby in the policy file.grant third party code no permissions or limited permissions ie file read but not write.This should solve it.Warm regards.
I'm in the exact same position and I try to use the answer here to work the problem out. But I have a follow up question.
I want to do something like this.
grant {
permission java.security.AllPermission;
};
and then I would want one specific codebase (to point out one singel class) which should NOT be granted AllPermission. But I don't find a way to invert the grant? Du I have to specify grant AllPermission for all codebases except the one I want to limit?!
/H
:-(
Is there a way to make a SecuritManager implementation that detects which class that made the checkXXX(..) and that way grant or not the different operations from one certain class? I tried this approach but wasn't able to find a way to detect which class did the call and therefore my "Rules" affected all classes and not just the one I wanted to target.
/H
Hey,
As far as I can tell SecurityManager is obselete... it remains for backwards compatibility and to serve as a flag that security is switched on. Other than that, it just provides convenience methodsv which delegate to AccessController.
Stop being lazy! Either:
(1) define a proper/decent policy file;
(2) redesign you security structure.
If you insist on doing things your way, forget about using Java's security infrastructure - fudge these ideas together will leave security holes.
Good luck,
Darren
Hi,
I was reading about the security manager and came across these clear words :
"However, there's an important detail here: the setSecurityManager() method is written in such a way that it can only be called once. Once a particular security manager has been installed, that security manager will be used by every other class that runs in this virtual machine. Once the policy is established, it cannot be changed (although the policy itself might be very fluid). "
now does it mean that custom setting of security manager for different classes is not possible? Please correct me if I am wrong.
regards
Hey,
You can swap the SecurityManager as much as you like given you have the permission to do so.
Quoting the API:
' If there is a security manager already installed, this method first calls the security manager's checkPermission method with a RuntimePermission("setSecurityManager") permission to ensure it's ok to replace the existing security manager. This may result in throwing a SecurityException.
Otherwise, the argument is established as the current security manager. If the argument is null and no security manager has been established, then no action is taken and the method simply returns.'
I retract what I said about it being obsolete; extend it and implement some convenience methods to take a Class parameter or access the thread stack to determine the calling class.
How old is the article you quoted? I have a feeling it was not published by Sun? You can change the policy, again, as long as you have permission to do so while a security manager is in effect.
Quoting the API:
'Sets the system-wide Policy object. This method first calls SecurityManager.checkPermission with a SecurityPermission("setPolicy") permission to ensure it's ok to set the Policy.'
Give a whirl - test some code?
Goodluck,
Darren
the url of the text extract is
"http://www.unix.org.ua/orelly/java-ent/security/ch04_03.htm"
which is the official site of oreilly associates and I dont think that they will be saying anything just like that. Look under the topic "Class definition" and you can easily see whatever extract I posted in my previous post, written there.
regards
Hi,
During permission check JRTS looks into the stack frame execution context (the list of classes in the stack). An access is granted if all the classes in the current execution stack have that permission. When A tries to access a resource directly B is not in the execution stack. So permission will be granted. When B requests for a resource directly both A and B will be in the execution stack. Since B does not have the permission, the access will not be granted. Thus I think you can do what you want to do. But if you try to access a resource while B is loaded A will not be granted, since B is in the execution stack. For solution you may load B in a method that is A's method, say withB( ). After you return from withB( ), B is no longer loaded and is not in the current execution stack. For reference look into "Inside Java2 Platform-Architecture API design and Implementation", 2nd edition by Sun Microsystem Pages 94-98.
I hope your problem will be solved.
Take care
Huda
Hey guys,
crack_it:
If you would rather dismiss the (A)pplication (P)rogramming (I)nterface then go ahead. No disrespect to the folks at O'Reilly, but reading the API is as good as hearing it from the horses mouth. If you could humour me, just test what the API says.
I can't remember if we discussed it somewhere at some point, but I am under the impression you are locking-down you application designed in a plugin-architecture.
If this is true, you simply need to specify two entries in your policy: one for your code in app_home/lib; one for third-party code in app_home/plugins. How you load these classes are irrelevant.
As for detecting which classes trigger security checks, as mmhuda says, you can access the execution stack through the Thread class. You can retrieve information on the calling class and its method which made the call. These 'calls' are stacked i.e. most recent first. You may need to skip 3 or 4 frames (StackTraceElements) which represent the calls to access the stack information. It is troublesome. I recently implemented a similar method wihtin my Policy implementation to prevent it from being wrapped and exploited by other bogus policy implementations. I have a lookup of class.method --> class.method strings that represent permitted calls. All you would need to do is implement a lookup mapping class or class.method --> Permission or Permissions (PermissionCollection) containing what the class can do, and check against them.
Now I have stated it, I am even more convinced; you are simply reimplementing the security infrastructure,or rather, shifting the function of the Policy and AccessController to your XxxxSecurityManager. Perhaps a waste of effort.
mmhuda:
Do not confuse terms; a class can be loaded and not in the execution stack - I wouldn't be surprised if a loaded class spends 99.99% of its life sitting idle off the stack. The stack represents a 'chain' of method calls for a particular Thread. It does not represent all the loaded classes in the JVM, otherwise the stack would be 100's of frames deep.
Warm regards,
D
Hi,
External codes (i.e. Applet) always have an open channel back to the origin. In other words, a downloaded code is granted permission to connect back to the origin server (Ref: Inside Java 2 Platform Security-2nd edition, page 84 (2nd para)). I want all external code not to be allowed to connect with outside, not even to the originator. My question: Is it possible to do so with the policy tool? If yes, how? Or, do I need to write checkpermission method?
bishopd81: thx for pointing out the (no) relation of all loaded classes and the contents of the execution stack.
regards
Huda
