Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SecurityManager surprises

I wanted to create a very restrictive security manager, so I extended SecurityManager and overridden all the custom checkXXX methods.

But then I found out that my security manager is useless, because anyone can just:

System.setSecurityManager(null);

So I have to add:

@Override    public void checkPermission(Permission perm)  {
    if (perm.getName().equals("setSecurityManager")) {
        throw new SecurityException("You shall have no other security manager but me!");
    }
}

Are there any more surprises? Any other things I have to do to make my SecurityManager hermetic?

like image 620
Erel Segal-Halevi Avatar asked Aug 03 '11 05:08

Erel Segal-Halevi


People also ask

What is SecurityManager in Java?

The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed.

Is it recommended to extend the SecurityManager class and override existing methods?

When extending the SecurityManager class and overriding existing methods, some care should be taken. For example, if you override the checkRead(String file) method so it always throws a security exception, then the JDK itself may fail to operate properly.

Which class is responsible for permission checks?

The security manager is a class that controls whether a specific operation is permitted. Operations checked by the security manager include the following: Creating a new class loader. Exiting the virtual machine.

Does the JVM provide a default security manager?

Reading a file or writing one also belong to the set of potentially dangerous operations. Fortunately, the JVM has a system to restrict those operations. Unfortunately, it's not set by default. In order to activate the SecurityManager, just launch the JVM with the java.


1 Answers

There are at least a couple of things I can think of:

  1. Someone could use reflection to set the System.security field to accessible, and then set it to whatever they want.

  2. Someone could use sun.misc.Unsafe to directly overwrite your instance in memory with whatever random thing they want.

I think your SecurityManager can guard against these things, since they both rely on calls to Field.setAccessible(). But better to test it out to make sure.

like image 114
aroth Avatar answered Oct 13 '22 11:10

aroth