The Security Manager

Everything you never wanted to know but have been forced to ask

Presentation Prepared By:
David M. Lloyd <david.lloyd@redhat.com>

What is it good for?

  • Protecting against access to certain JVM facilities...
    • ...like System.exit()
  • Restricting filesystem access (as long as only JDK APIs are used)
  • Restricting network access (directly or via services like JDBC, HTTP, etc.)
  • Restricting access to security facilities (JAAS authentication, etc.)
  • Running trusted or mostly trusted code

What is it not good for?

  • Cannot protect against runaway CPU consumption
  • Cannot restrict memory consumption
  • Running truly untrusted code
  • Only the OS can truly provide this protection

Why use it?

  • Some orgs have hard requirements for various reasons
  • Common Criteria certification
  • Can be used to catch bugs, theoretically

How do you use it?

  1. Establish a security policy
    • Use a standard policy file
    • Use JBoss Modules <permissions> blocks in your modules
    • Use Java EE 7 permissions.xml files in an EE 7 container
    • Use Java EE 7 specified, container-defined global default permission policies
      • In WildFly, this lives in the security-manager subsystem
  2. Enable the security manager
    • In a standalone JVM, -Djava.security.manager
    • In a standalone JBoss Modules application, -secmgr
    • In WildFly 8, just configure the security-manager subsystem
    • In WildFly 9+ and EAP 6.4+ and 7+, set SECMGR to "true" in standalone.conf or pass -secmgr to the start script (with or without the subsystem configured)
      • permissions.xml only works with the subsystem though!

How are permissions assigned?

  • Every class is associated with a protection domain, which consists of:
    • A link to the defining class loader of the class
    • A code source (a URL that identifies the code)
    • A permission collection (a set of assigned permissions)
    • An array of principals, specific to JAAS
  • The protection domain permissions are built from the security policy (whatever its source)

How are permissions checked?

  • The security manager examines the current access control context
  • This is the accumulation of the protection domains of classes from the call stack
  • The permission check passes only if all the security domains in the access control context have granted the permission

How do you diagnose access problems?

  • AccessControlException
    • Information is very minimal, typically something like: 
      access denied: java.lang.RuntimePermission("blah", "")
    • There is a "debug" facility... but it's useless

WildFly Security Manager to the rescue

  • Gives permission that failed, the code source that lacked the permission, and its class loader in the exception message
  • Logs all access violations (with complete stack trace) at level DEBUG in category org.wildfly.security.access

How do you solve access problems?

  1. Identify the code performing the checked action
  2. Identify the code source of the denial
  3. Choose one resolution:
    • Grant the missing permission to the denied code source
    • Replace your common unprivileged operation with one of the privileged versions from the WildFly Security Manager
      • getPropertyPrivileged
      • getClassLoaderPrivileged
      • getCurrentContextClassLoaderPrivileged
      • These only work when the WildFly Security Manager is the active Security Manager
    • Add a doPrivileged block into the intervening call stack
      • Carefully
      • And only as a last resort

Being safe with privilege

  • For better or worse, many users rely on the security manager to actually provide some measure of security
  • It is easy to accidentally defeat the security manager
    • Also known as a security vulnerability
  • There are some important guidelines to follow to avoid introducing vulnerabilities

Being safe with privilege: Guidelines

  • Never perform a privileged action that isn't in turn protected by another permission check
    • Or a very good reason
  • Never execute privileged actions from strangers
    • You cannot assume that potentially harmful privileged actions only come from untrusted code
    • We ship dozens of them out of the box as public classes in code bases routinely granted AllPermission
  • Never assume AccessControlContexts are "honest"
    • They are trivially constructable with arbitrary protection domains
    • Untrusted ACCs are particularly dangerous in combination with untrusted privileged actions
    • AccessController.doPrivileged() gets away with this by merging in the caller's permissions
    • If you need a captured ACC, capture it yourself with AccessController.getContext()

Authoring custom permissions

  • Must extend java.security.Permission
  • Must have two constructors
    • YourPermission(String name)
    • YourPermission(String name, String actions)
  • Even if you don't support actions

Custom permission guidelines

  • Use BasicPermission for simple, hierarchical names
  • org.wildfly.security.permission.PermissionActions

Permission serializability

  • Permissions are serializable
  • Fixed serialVersionUID
  • Compatibility

WildFly Security Manager

WildFly Security Manager Features

  • Unchecked mode
    • Executes privileged action blocks with permission checking turned off
    • Used in performance-sensitive internal code
    • Requires the caller to have a specific permission
    • Use very carefully

WildFly Security Manager Features

  • Parameterized privileged actions
    • Pass a parameter in to a privileged action
    • Avoid allocations in some cases
    • Only faster if WFSM is installed

WildFly Security Manager Features

  • Non-throwing permission checks
    • Avoid overhead of access exception for simple tests
    • Only faster if WFSM is installed

WildFly Security Manager Features

  • Caller checking utility methods
    • Perform common actions without privileged blocks, like:
      • Get/set/clear system properties
      • Get a class' class loader
      • Get/set the TCCL
    • Only faster if WFSM is installed

WildFly Security Manager Features

  • Stack inspector
    • A common API to determine the calling class
    • Automatically chooses the fastest available method
    • Requires permission to acquire the inspector instance

WildFly Security Manager Features

  • Collection of common privileged actions

Future of WildFly Security Manager

Security Manager related features in Java 8

  • Limited doPrivileged - run privileged actions with only a subset of your total possible permissions

Security Manager related features in Java 9

  • Not much determined yet...
  • It is likely that protection domain permissions will be bound to whole modules instead of individual classes (similarly to how JBoss Modules behaves)
  • However it is also likely that individual classes will be able to be "lowered" to a more restricted permission set

That's it!