Is there a way to force Security check if an app's code doesn't call it?
I want to make it so I can set my own implementation of SecurityManager to do a check before ALL method calls.
This way, people can plug their apps into my system and not have to make sure they write in those security checks themselves.
Then All they have to do is set up permissions for it.
So my SecurityManager would have a mapping like:
<class namespace="com.me.package" name="aClass">
<method name="check" signature="{int, int}">
<access level="read">
<principal name="joe"/>
</access>
</method>
</class>
then i'd translate that into permissions. So on every call, i just look up the method and see if they have rights.
This way, the writer of "aClass" does not have to call:
SecurityManager sm = System.getSecurityManager();
sm.checkXXX(....);
Anyone know if this is possible?
[1120 byte] By [
6tr6tr] at [2007-9-26 4:55:40]

Ok ... I didn't quite that.
You'll have to implement your own SecurityManager. Create a class the extends SecurityManager and then set it as the default SecurityManager on your code startup.
public class MySecurityManager extends SecurityManager
{
public MySecurityManager()
{
super();
}
/**Allow this function for us */
public void checkExec(String cmd){
// check my policy
if (ok)
return;
else
Throw new SecurityException("Can't exec a system command");
}
..
..
}
MySecurityManager mySecure = new MySecurityManager();
mySecure.setMyPolicy(); // to establish your rules
System.setSecurityManager(mySecure);
In your security manager you include the logic to implement your policies. Basically the routinesthrow an exception unless the function is allowed, in which case it just terminates.
No That one is used to check if you can execuate a system call.
Builtin security has hooks into various functions which define the services available in the sandbox.
Look at the SecurityManager class to see what is and is not protected. Mostly local things are protected from applets, as well as the ability to dynamically switch to sites where they didn't originate from. This includes prt numbers etc.
You don't have to woory about anything else, since it isn;t protected in the first place.
No if you want to create your own hooks to protect other things ... not normally protected ... thats a totally different topic. I assume you don't want to do that because I guess you are trying to make it easier .. not harder.
The simplest way to do this would be to include a method in your security manager and hook it into the major 'Other Functions' you want protected .. at least then you can still implement yopur policy rules. Otherwise you have to go looking for functions using reflection and then hook them to include a call to you .. seems like a lot of work.
Not really sure how that would be accomplished ... unless you took the virus approach and front-ended the byte code with your call first.
NO. If you write a class with two methods foo() and bar() then there is no way for any security manager to trap foo()'s calls to bar(). And thank God for that -- Java is
pretty slow as it is, we don't want more overhead.
Security should be applied to sensitive operations. That's why certain methods in the core API are protected. The same does not apply to every other method in the world.
To accomplish what you want is quite hard: you need a custom classloader that instruments bytecode on the fly to insert hooks into methods bytecode that call back into your "security manager".
Vlad.