Class NoSecurityManager
- java.lang.Object
-
- java.lang.SecurityManager
-
- gnu.cajo.invoke.NoSecurityManager
-
public final class NoSecurityManager extends java.lang.SecurityManager
This utility class creates a trivial SecurityManager for developing proxy hosting clients. It allows trusted clients and servers to operate without restriction, and without the need for a security policy file. It effectively allows both clients and proxies full permissions on the machine. While this is very convenient for development purposes, this clearly would be very unwise to use in an untrusted environment. In production, the user better impose his own security policy, and use the following two interpreter switces:-Djava.security.manager -Djava.security.policy=someURL
This URL, or file, would contain the restrictions governing what both the loaded proxy code, and the client code, are permitted to do. A minimal, but functional policy file, would contain at least the following:
grant { permission java.net.SocketPermission "*:1024-", "accept"; permission java.net.SocketPermission "*", "connect"; };
This would allow the client, and its loaded code to open server sockets on port 1024 and higher, and to connect to remote hosts on any port, and nothing else. It is slightly more permissive than a standard applet sandbox, but still very safe for hosting machines. Any attempt to install a SecurityManager should enclose the operation in a try/catch block, as the operation may be forbidden by the user via the technique described above. The assignment would then result in the throwing of a SecurityException.
If the server code is fully trusted, a more flexible policy file could be used such as:
grant codeBase "file:${java.class.path}" { permission java.security.AllPermission; }; grant { permission java.net.SocketPermission "*:1024-", "accept"; permission java.net.SocketPermission "*", "connect"; };
This will allow classes loaded from the local filesystem full permissions, while only allowing downloaded code to make socket connections in the manner of the first policy file.
Note: either way, to allow proxies to run within this VM invites the possibility of a denial of service attack, i.e. a proxy or, other object, could consume all the VMs memory and compute cycles maliciously, or even accidentially. Therefore, it is recommended that proxy hosting only be done on an expendible VM.
-
-
Constructor Summary
Constructors Constructor Description NoSecurityManager()
Nothing is performed in the constructor.
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description void
checkPermission(java.security.Permission perm)
In accordance with the SecurityManager paradigm, this method simply returns, to indicate that a requested client operation is permitted.-
Methods inherited from class java.lang.SecurityManager
checkAccept, checkAccess, checkAccess, checkConnect, checkConnect, checkCreateClassLoader, checkDelete, checkExec, checkExit, checkLink, checkListen, checkMulticast, checkMulticast, checkPackageAccess, checkPackageDefinition, checkPermission, checkPrintJobAccess, checkPropertiesAccess, checkPropertyAccess, checkRead, checkRead, checkRead, checkSecurityAccess, checkSetFactory, checkWrite, checkWrite, getClassContext, getSecurityContext, getThreadGroup
-
-
-
-
Method Detail
-
checkPermission
public void checkPermission(java.security.Permission perm)
In accordance with the SecurityManager paradigm, this method simply returns, to indicate that a requested client operation is permitted. Otherwise it could throw a SecurityException, but it never does. This means, that without an explicitly specified policy file used in the startup of an application using this security manager, BOTH the client, and its loaded proxies have full permissions on this machine.- Overrides:
checkPermission
in classjava.lang.SecurityManager
-
-