SecurityManager Sınıfı

Giriş
Şu satırı dahil ederiz

import java.lang.SecurityManager;

Açıklaması şöyle

SecurityManager is designed so you can run untrusted bytecode securely within Java applications. SecurityManager sandboxes the bytecode in order to prevent attacks.

Açıklaması şöyle

 the Oracle team deprecated the Security Manager in Java 17. One of the arguments it based its decision on is that it was initially designed to protect against applets. Applets were downloaded from the Internet, so they had to be considered untrusted code. Hence, we had to run them in a sandbox.

...

The Security Manager was a JVM component that allowed you to define a white list of what an application could do, regardless of the application code. It solved all the above issues: you could run any code but only allowed it to do a limited number of things.

The Security Manager came with several drawbacks; chief amongst them is that it was a bore to configure permissions. However, there are tools to generate the policy file. Since they are automated, you need to review the discovered permissions carefully. It’s easier to read through ~500 lines of configuration than 10k or 100k lines of code.

Since many didn’t know about tools, few did use the Security Manager. But when it was, it was very beneficial. 

Bir başka açıklama şöyle

With the arrival of Java 24, the SecurityManager is now officially gone. It's worth taking a minute to reflect on what the SecurityManager was, why it was a failure, and what security lessons we can take away from it.

In the olden days, when some thought that Java was going to rule the web (remember "applets"?), they wanted a way to run code downloaded from the Internet safely, so they developed the SecurityManager. The Java runtime would execute applications under the SecurityManager, which enforced restrictions on whether they could access system resources like the network and filesystem. If code tried to violate the restrictions, the runtime would throw a SecurityException.

The design required core Java libraries - those that start with 'java.' and handle network, file, and other vital operations - to implement these security checks. The libraries themselves had full permissions; when you tried to make a call to, say, write a file, that code would check to see if you could, and permit or deny access accordingly. 

This created a situation where any vulnerability discovered in these libraries could potentially bypass the SecurityManager's protections. All patches that went into the libraries had to be checked and double-checked to make sure that they couldn't be used to violate SecurityManager's safety guarantees.

The reliance on core libraries for security enforcement introduced a critical point of failure.

As a result, Java was subject to a repeated series of embarrassing bug reports: a new version would come out, new APIs were introduced, someone would find a way to use those APIs to bypass SecurityManager checks, and the whole thing would be repeated next time. If you could trick someone into downloading a malicious applet, you could take control of their entire system.

Between the ongoing reports of "someone found a way to bypass applet security", the fact that the security checks extracted a performance hit, and the fact that SecurityManagers were difficult to configure, they became legacy technology quickly.

One takeaway for software developers is quite simple: when you add security features, keep the potential attack surface small. If you can compromise your system by finding a flaw in any of hundreds of regularly updated APIs, your system will get compromised. It's not a coincidence that JavaScript only supports a very small number of local storage options.

And congrats to the team on finally getting rid of this 30 year old technical debt!