Class 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
      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
    • Constructor Detail

      • NoSecurityManager

        public NoSecurityManager()
        Nothing is performed in the constructor. This class exists only to short-circuit the permission checking mechanism of the Java runtime by overriding the checkPermission method with a bodyless implementation.
    • 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 class java.lang.SecurityManager