Further Defenses for the Security Manager

[Michael Maass]

 >Since java.security.Security properties are themselves protected by 
permission, why not "cut out the middleman" and just have a permission 
type which grants permission to load such a class directly?  Or is this 
what you're trying to avoid?  (If so, then it seems you need to add a: 
1a. If a self-protecting manager is set, security properties can never 
be modified.)

You are correct on the latter point and 1a should have been specified.

 >Also by "more privileged" I assume you mean, the protection domain of 
the class being loaded specifies permissions that the security manager 
class' protection domain itself does not imply?

This is correct.

 >Enforcing rule 2 is as simple as refusing any permission check for 
modifying the security manager, regardless of source protection domain, 
correct?

Also correct. If a self-protecting manager is set, no protection domain 
should change the manager.

Michael

On 10/29/2014 11:23 AM, David M. Lloyd wrote:
> On 10/29/2014 08:35 AM, Michael Maass wrote:
>> Hello All,
>>
>> I've spent the last 6 months working with some colleagues on a project
>> that aimed to stop an exploitation avenue that has been popular with
>> recent Java exploits: disabling the security manager. We think that what
>> ended up with may be worthy of a JEP and/or a prototype implementation
>> in the JVM; we're looking for feedback from the experts, you folks.
>>
>> We initially set out to determine how benign applications interact with
>> the security manager and to determine how those interactions differ from
>> malicious ones. The idea was that an investigation aimed at making these
>> determinations could show us ways to constrain operations on the manager
>> that are backwards compatible with benign applications while blocking
>> exploits.
>>
>> After investigating the open source Java landscape we learned to
>> distinguish between (1) "self-protecting" and "defenseless" security
>> managers and (2) the operations that may be performed in the presence of
>> each. A defenseless manager enforces a policy that uses at least one
>> permission in a set of permissions we identified that allow anyone to
>> change the manager itself or the policy it enforces (a self-protecting
>> manager is the opposite of a defenseless manager). Given this
>> definition, we found that enforcing the following rules stopped known
>> exploits without impeding (aside from overhead) the execution of benign
>> applications:
>>
>> 1. If a self-protecting manager is set, a class may not load or cause
>> the loading of a class more privileged than itself unless the loaded
>> class is in a protected package (listed in the package.access property
>> in java.security.Security).
>
> Since java.security.Security properties are themselves protected by 
> permission, why not "cut out the middleman" and just have a permission 
> type which grants permission to load such a class directly?  Or is 
> this what you're trying to avoid?  (If so, then it seems you need to 
> add a: 1a. If a self-protecting manager is set, security properties 
> can never be modified.)
>
> Also by "more privileged" I assume you mean, the protection domain of 
> the class being loaded specifies permissions that the security manager 
> class' protection domain itself does not imply?
>
>> 2. If a self-protecting manager is set, an application may not change
>> the security manager or the enforced policy in any way.
>>
>> We built a JVMTI agent to enforce these rules (available here:
>> https://github.com/SecurityManagerCodeBase/JavaSandboxFortifier).
>> Unfortunately, to use the JVMTI events that allow us to enforce rule 2,
>> the JIT must be off, which drastically slows down the execution of
>> applets in the presence of our agent. Rule 1 adds about 1-2% overhead.
>> We believe overhead would drop enough for adoption if the JVM were to
>> natively enforce these rules instead of using an agent, but we do not
>> have the resources or the expertise to try this ourselves.
>
> Enforcing rule 2 is as simple as refusing any permission check for 
> modifying the security manager, regardless of source protection 
> domain, correct?
>
>> Any thoughts on whether or not this type of change is worth pursing in
>> the form of a JEP and/or prototype in the JVM? If so, is anyone willing
>> and able to help?
>>
>> Thanks,
>>
>> Michael Maass, PhD Candidate
>> Software Engineering
>> Institute for Software Research
>> School of Computer Science
>> Carnegie Mellon University
>