As of Notes 6.x the JVM installed with Notes/Domino is a real Java 2 virtual machine which means that you have greater control over how security is handled. As mentioned previously you cannot install your own SecurityManager but you have the possibility to grant or restrict which access third-party libraries get.
As mentioned in my post called “Managing external Java dependencies in Domino Designer” you have a directory called jvm/lib/ext under your binary Notes/Domino directory. This directory can be used to install third-party or custom libraries which will always be on the classpath of Notes/Domino. What you maybe did not know is that the libraries placed in this directory is granted all permissions which means that they can really wreak havok on your system if they are malicious.
The permissions granted to external JAR-files in Notes/Domino are controlled through two files that are located in the jvm/lib/security directory called java.security and java.policy. The java.security file is a property file for classes in the java.security package – there is no need to worry about this file unless you start installing custom cryptographic extensions or modify the ones that are installed by default. The other file, java.policy, is however very usable and it is here you can control which permissions individual libraries get. This file is used by the installed SecurityManager to decide which operations to allow.
Below is a snippet from the default java.policy file:
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
// Notes java code gets all permissions
grant codeBase "file:${notes.binary}/*" {
permission java.security.AllPermission;
};
As you can see above the java.security.AllPermission permission is granted to all the files in jvm/lib/ext and to all files in the binary Notes/Domino directory. You can refer to the Javadocs for indepth information on java.security.AllPermission but suffice it to say that it allows everything. The syntax of the java.policy file also allows you to grant permissions if a library is digitally signed (see below for a link to a page describing the syntax of the java.policy in detail).
The java.security.AllPermission is a lot of access to any given library and it shouldn’t be granted lightly. Consider the source of the library, who compiled it and what the library should do before granting access. As always only grant the access that is actually needed – don’t just give java.security.AllPermissions because it is easier…
java.security.AllPermission shouldn’t be granted lightly…
There are a host of other types of permissions that may be granted (see the sub-classes of java.security.Permission) incl. access to reading and writing specific files or directories to access to network resources etc. In fact the java.security.FilePermission is probably the permission most commonly used since it allows you to grant a library access to files in a specific directory. Using java.security.FilePermission you can distinguish between reading, writing and executing files.
This is a point where Java allows you much more fine grained control than LotusScript. In LotusScript you have access to I/O or you don’t – in Java you can actually control which files a library may work with.
That is all for now. The next and final installment on security will discuss how third-party libraries actually use the permissions granted to them by the SecurityManager.
Further reading
If I include an external jar file directly in the agent with a self-signed test certificate (done through keytool) and give permissions for that signature in the policy file, will JVM recognize it? In otherwords, the policy defined there should also be applicable to the external jar files I put directly in the agent through “Edit Project”. It doesn’t seem to work for me.
I don’t think it will work – the policy file, which is tricky enough to get working, only seems to work for jar-files in the jvm/lib/ext directory. Furthermore you will need to add your certificate to the keystore used by Domino to have it validate the signature.
Thanks Mikkel.
I generated a keystore, added a certificate to it(using -selfcert with keytool), signed the jar file and included my keystore in the policy file through policytool – so I expected that to look up mine instead of Domino’s.
Anyway, I think it’s better to go with jvm/lib/ext or add permission to the default “grant” for all signatures. Thanks!
getting an “LS2J error: Illegal Signature.” when I try to pass a class to another java classes constructor through lotus script. Can’t figure this one out. I’m assigning the class object to a variant in script and then passing the variant to the java class via LS2J. works on the java side but not on the notes side. am passing class like jObject(“com/ibm/myClass”,myclassobj) where myClass is the name of the java class that is being passed to another java class via lotus script through LS2J.
“Illegal signature” sounds like something that would occur if you call a method on the Java object from LotusScript with different parameters than what the Java object expects. I guess all method invocations via LS2J is done through reflection-like technology so the LotusScript side of the code has no way to knowing which methods are actually available on the Java end of things. Sort of like late-binding when doing COM development on Windows.
I would start by checking that the method signature you call is correct that is that the method name is right and that the supplied parameters are of the correct datatype.
Let me hear how it goes.
Yeah I figured out the illegal signature problem. I was passing a user defined class from Lotus script to java via LS2J. I finally had to fully qualify the signature of the constructor ie: “(Lcom/ibm/host/HostDefinition;)V”. The problem I ran into after that is that I got a message that said “LS2J error: java constructor failed to execute”. This works on the java side so the only thing I can conclude after many hours trying to get this to work is that you can only pass primitive data types to a java constructor or method via LS2J.