为什么Java Security Manager不是强制性的？

Question

One of the benifits of java language is we say it is secure language. But security manager is not mandatory by default. And by default we can have many issues like accessing private objects with reflection. Little confused on why it is designed so, can you please provide more points on this.

Answer 1

One of the benefits of java language is we say it is secure language.

I would disagree with that proposition:

• Java is not a (sufficiently) secure language to absolve the programmer of thinking about security. Certainly it is not good enough for running untrusted code in a browser plugin. I would not call Java a secure language.

• I'm not convinced that more security would be of benefit for a most Java applications.

But security manager is not mandatory by default.

Correct.

And by default we can have many issues like accessing private objects with reflection.

Private visibility was never designed as a security feature. It is a feature for enforcing encapsulation of Java's "abstract data types"; ie classes.

The reason that reflection is allowed to override the visibility rules is that it is sometimes necessary to break encapsulation for pragmatic reasons. It is most frequently done in abstraction cross-cutting functionality like dependency injection frameworks, serialization mechanisms where the concerns that encapsulation aims to address (eg unwanted coupling) are moot.

In short, I don't see this as an issue that needs to be addressed ... for most Java application. If an application or 3rd party library is using reflection that way, there is probably a good reason for doing it.

---

Now I accept that some problem domains require a much higher level of security than a typical Java application. For them, by all means implement a security manager ... and block reflective access to private variables. However, I suggests that if your security requirements are such that you need to block encapsulation breaking, then a security manager is not sufficient to address the other security concerns that you have to deal with.

The classic approach to dealing with hard security requirements involves vetting your developers and operations staff, independent auditing of your code base, intrusion testing, and so on ... and air gaps.