How to limit setAccessible to only "legitimate" uses?

The more I learned about the power of java.lang.reflect.AccessibleObject.setAccessible, the more astonished I am at what it can do. This is adapted from my answer to the question (Using reflection to change static final File.separatorChar for unit testing).

import java.lang.reflect.*;

public class EverythingIsTrue {
   static void setFinalStatic(Field field, Object newValue) throws Exception {
      field.setAccessible(true);

      Field modifiersField = Field.class.getDeclaredField("modifiers");
      modifiersField.setAccessible(true);
      modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

      field.set(null, newValue);
   }
   public static void main(String args[]) throws Exception {      
      setFinalStatic(Boolean.class.getField("FALSE"), true);

      System.out.format("Everything is %s", false); // "Everything is true"
   }
}

You can do truly outrageous stuff:

public class UltimateAnswerToEverything {
   static Integer[] ultimateAnswer() {
      Integer[] ret = new Integer[256];
      java.util.Arrays.fill(ret, 42);
      return ret;
   }   
   public static void main(String args[]) throws Exception {
      EverythingIsTrue.setFinalStatic(
         Class.forName("java.lang.Integer$IntegerCache")
            .getDeclaredField("cache"),
         ultimateAnswer()
      );
      System.out.format("6 * 9 = %d", 6 * 9); // "6 * 9 = 42"
   }
}

Presumably the API designers realize how abusable setAccessible can be, but must have conceded that it has legitimate uses to provide it. So my questions are:

• What are the truly legitimate uses for setAccessible?
  • Could Java has been designed as to NOT have this need in the first place?
  • What would the negative consequences (if any) of such design be?
• Can you restrict setAccessible to legitimate uses only?
  • Is it only through SecurityManager?
    • How does it work? Whitelist/blacklist, granularity, etc?
    • Is it common to have to configure it in your applications?
  • Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration?
    • Or am I at the mercy of whoever manages the configuration?

I guess one more important question is: DO I NEED TO WORRY ABOUT THIS???

None of my classes have any semblance of enforceable privacy what-so-ever. The singleton pattern (putting doubts about its merits aside) is now impossible to enforce. As my snippets above show, even some basic assumptions of how Java fundamental works is not even close to being guaranteed.

ARE THESE PROBLEMS NOT REAL???

Okay, I just confirmed: thanks to setAccessible, Java strings are NOT immutable.

import java.lang.reflect.*;

public class MutableStrings {
   static void mutate(String s) throws Exception {
      Field value = String.class.getDeclaredField("value");
      value.setAccessible(true);
      value.set(s, s.toUpperCase().toCharArray());
   }   
   public static void main(String args[]) throws Exception {
      final String s = "Hello world!";
      System.out.println(s); // "Hello world!"
      mutate(s);
      System.out.println(s); // "HELLO WORLD!"
   }
}

Am I the only one who thinks this is a HUGE concern?

DO I NEED TO WORRY ABOUT THIS???

That depends entirely on what types of programs you're writing and for what kind of an architecture.

If you're distributing a software component called foo.jar to the people of the world, you're completely at their mercy anyway. They could modify the class definitions inside your .jar (through reverse engineering or direct bytecode manipulation). They could run your code in their own JVM, etc. In this case worrying will do you no good.

If you're writing a web-application that only interfaces with people and systems via HTTP and you control the application server, it's also not a concern. Sure the fellow coders at your company may create code that breaks your singleton pattern, but only if they really want to.

If your future job is writing code at Sun Microsystems/Oracle and you're tasked with writing code for the Java core or other trusted components, it's something you should be aware of. Worrying, however, will just make you lose your hair. In any case they'll probably make you read the Secure Coding Guidelines along with internal documentation.

If you're going to be writing Java applets, the security framework is something you should be aware of. You'll find that unsigned applets trying to call setAccessible will just result in a SecurityException.

setAccessible is not the only thing that goes around conventional integrity checks. There's a non-API, core Java class called sun.misc.Unsafe that can do pretty much anything at all it wants to, including accessing memory directly. Native code (JNI) can go around this kind of control as well.

In a sandboxed environment (for example Java Applets, JavaFX), each class has a set of permissions and access to Unsafe, setAccessible and defining native implementations are controlled by the SecurityManager.

"Java access modifiers are not intended to be a security mechanism."

That very much depends on where the Java code is being run. The core Java classes do use access modifiers as a security mechanism to enforce the sandbox.

What are the truly legitimate uses for setAccessible?

The Java core classes use it as an easy way to access stuff that has to remain private for security reasons. As an example, the Java Serialization framework uses it to invoke private object constructors when deserializing objects. Someone mentioned System.setErr, and it would be a good example, but curiously the System class methods setOut/setErr/setIn all use native code for setting the value of the final field.

Another obvious legitimate use are the frameworks (persistence, web frameworks, injection) that need to peek into the insides of objects.

Debuggers, in my opinion, don't fall into this category, as they normally don't run in the same JVM process, but instead the interface with the JVM using other means (JPDA).

Could Java has been designed as to NOT have this need in the first place?

That's a pretty deep question to answer well. I imagine yes, but you'd need to add some other mechanism(s) that might not be all that preferrable.

Can you restrict setAccessible to legitimate uses only?

The most straight-forward OOTB restriction you can apply is to have a SecurityManager and allow setAccessible only to code coming from certain sources. This is what Java already does - the standard Java classes that come from your JAVA_HOME are allowed to do setAccessible, while unsigned applet classes from foo.com aren't allowed to do setAccessible. As was said before, this permission is binary, in the sense that one either has it or not. There is no obvious way to allow setAccessible to modify certain fields/methods while disallowing others. Using the SecurityManager you could, however, disallow classes from referencing certain packages completely, with or without reflection.

Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration? ... Or am I at the mercy of whoever manages the configuration?

You can't and you most certainly are.

• What are the truly legitimate uses for setAccessible?

Unit testing, internals of the JVM (e.g. implementing System.setError(...)) and so on.

• Could Java has been designed as to NOT have this need in the first place?
• What would the negative consequences (if any) of such design be?

Lots of things would be unimplementable. For example, various Java persistence, serialization and dependency injections are reliant on reflection. And pretty much anything that relies on the JavaBeans conventions at runtime.

• Can you restrict setAccessible to legitimate uses only?
• Is it only through SecurityManager?

Yes.

I'm not saying that doing this through the SecurityManager and blacklists / whitelists is a good idea. I'm saying that it is (AFAIK) the only way to do this.

Also, note that Java 17 marks SecurityManager as deprecated; for removal. See JEP 411. That is a reason that this another bad idea.

• How does it work? Whitelist/blacklist, granularity, etc?

It depends on the permission, but I believe that the permission to use setAccessible is binary. If you want granularity, you need to either use a different class loader with a different security manager for the classes that you want to restrict. I guess you could implement a custom security manager that implements finer grained logic.

• Is it common to have to configure it in your applications?

No.

• Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration?
• Or am I at the mercy of whoever manages the configuration?

No you cannot, and yes you are.

The other alternative is to "enforce" this via source-code analysis tools; e.g. custom pmd or findbugs rules. Or selective code review of code identified by (say) grep setAccessible ....

In response to the followup

None of my classes have any semblance of enforceable privacy what-so-ever. The singleton pattern (putting doubts about its merits aside) is now impossible to enforce.

If that worries you, then I suppose you need to worry. But really you should not be trying to force other programmers to respect your design decisions. If people are stupid enough to use reflection to gratuitously create multiple instances of your singletons (for example), they can live with the consequences.

On the other hand, if you mean "privacy" to encompass the meaning of protecting sensitive information from disclosure, you are barking up the wrong tree. The way to protect sensitive data in a Java application is not to allow untrusted code into the security sandbox that deals with sensitive data. Java access modifiers are not intended to be a security mechanism.

<String example> - Am I the only one who thinks this is a HUGE concern?

Probably not the only one :-). But IMO, this is not a concern. It is accepted fact that untrusted code should be executed in a sandbox. If you have trusted code / a trusted programmer doing things like this, then your problems are worse than unexpectedly mutable Strings. (Think logic bombs, exfiltration of data via covert channels, etcetera)

There are ways to deal with (or mitigate) the problem of a "bad actor" in your development or operations team. But they are costly and restrictive ... and overkill for most use-cases.