Saturday, November 22, 2014

Java SecurityManager: "java.security" and "java.policy" Files

In many cases, where the threat model does not include malicious code being run in the JVM, the Java Security Manager[1] is unnecessary. However, when untrusted third-parties use WebLogic Server[2] and untrusted classes are being run, the Java Security Manager may be useful.

In this article, we will discuss the following topics:
  1. What is Java Security Manager?
  2. What is "java.security" file?
  3. What is "java.policy" file?

Java Security Manager


The JVM has security mechanisms built into it that allow you to define restrictions to code through Java security policy files (i.e., java.policy file). The Java Security Manager uses these policies to enforce a set of permissions granted to classes. The permissions allow specified classes running in that instance of the JVM to allow or not allow certain runtime operations.

Therefore Java Security Manager can be used with WebLogic Server to provide additional protection for resources running in a Java Virtual Machine (JVM).[1] However, using a Java Security Manager is an optional security step.

To use the Java Security Manager with WebLogic Server, just specify:
-Djava.security.manager -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy
arguments when starting WebLogic Server. The -Djava.security.policy argument specifies a filename (using a relative or fully-qualified pathname) that contains Java 2 security policies.[5] If weblogic.policy file is provided, then the specified policy file will be loaded in addition to all the policy files that are specified in the security properties file (see "java.policy" section).  If you instead type the following command options, using a double equals, then just the specified policy file will be used; all others will be ignored:
-Djava.security.manager -Djava.security.policy==${WL_HOME}/server/lib/weblogic.policy

java.security


A security model can be as simple as the one supported in Linux or Windows file system—file permissions are granted to principals based on user IDs. Or it can be as sophisticated as the one implemented in Adobe Flash Player (see [6] for details). Java Security Manager supports a security model sits in between the two in terms of complexity and capability.

Sometimes a Java application (like, say, a Web browser) needs to run untrusted code within itself. In this case, Java system libraries need some way of distinguishing between calls originating in untrusted code and calls originating from the trusted application itself. Clearly, the calls originating in untrusted code need to be restricted to prevent hostile activities. By contrast, calls originating in the application itself should be allowed to proceed (as long as they follow any security rules that the operating system mandates).

Security is all about separation by creating protection domains. Access control in Java Security Manager is enforced with the help of:[10]
  • Executable Code Identity
    • Decisions are based on the identity of the executable code
      • AccessController in java.security package consults policy and uses stack inspection (see below) to decide whether to allow or disallow a call.
    • Executable code is categorized based on its URL of origin and the private keys used to sign the code:
      • Code source
        • Note that permission objects are associated with each code source
      • Signature
    • Trusted code vs untrusted code
  • Protected System Resource
    • File access
    • Network access (via sockets)
    • Listening ports, etc.
  • Permission (or privilege)
    • Permission is configure by:
      • Grant Target
        • Such as the name of a file
      • Grant Action
        • Such as "read" action on a file
    • Collection of Permissions
      • Homogeneous vs heterogeneous
  • Logical groupings
    • Separating groups from each other and granting groups particular permissions.

Stack Inspection

Java implements its security system by allowing security-checking code to examine the runtime stack for frames executing untrusted code. This is called stack inspection.[7] Java Security Manager inspects the stack in order to make access control decisions.

Each thread of execution has its own runtime stack. The stack grows and shrinks during typical program operation. Each stack frame includes both a method call and a trust label (T for trusted, U for untrusted).

Security Properties File Location

The security properties file is located in the file named

java.home/lib/security/java.security (Solaris/Linux/Mac OS X)
java.home\lib\security\java.security (Windows)

java.policy


Java security can be dictated by security policies. A policy file can be composed via a simple text editor, or via the graphical Policy Tool utility.[8] There is by default a single system-wide policy file, and a single (optional) user policy file. Policy can be set by the user (usually a bad idea) or by the system administrator, and is represented in the class java.security.Policy.

The configuration file(s) specify what permissions are allowed for code from a specified code source, and executed by a specified principal. Each configuration file must be encoded in UTF-8.[4]

Policy File Location

Policy file locations are specified in the security properties file (i.e., java.security).  For example, the default system and user policy files are defined using URL specification in the security properties file as:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy


System Policy File

The system policy file is meant to grant system-wide code permissions. It is by default located at

java.home/lib/security/java.policy (Solaris/Linux/Mac OS X) 
java.home\lib\security\java.policy (Windows)

The java.policy file installed with the JDK grants all permissions to standard extensions, allows anyone to listen on un-privileged ports, and allows any code to read certain "standard" properties that are not security-sensitive, such as the "os.name" and "file.separator" properties.

 Executable code is categorized based on its URL of origin and the private keys used to sign the code. The security policy maps a set of access permissions to code characterized by particular origin/signature information. Protection domains can be created on demand and are tied to code with particular CodeBase and SignedBy properties.

Code can be signed with multiple keys and can potentially match multiple policy entries. In this case, permissions are granted in an additive fashion

References



at

No comments:

Post a Comment