JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

On 5/05/2021 10:55 pm, Sean Mullan wrote:
> -
>> Obviously we won't have a call stack with domains, I don't know how 
>> we will transfer the user Subject to other threads, for TLS and 
>> Kerberos connections.  No doubt something is planned.
>
> There is a plan for preserving the capability to transfer Subjects to 
> other threads. It is described in the JEP:
>
> https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs
>
> --Sean


Thanks for the reference Sean.


>
>>
>> Is the recommendation simply not to upgrade Java until new access 
>> control API is developed?
>>
>>
>> <SNIP>
>>>> Please provide some examples, migration options suggestions will be 
>>>> appreciated.
>>> I’ve jotted down some thoughts in a blog post: 
>>> https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ 
>>>
>>
Please read the following carefully and ask questions to clarify if needed.

OpenJDK seems to have assumed that no one was using SecurityManager 
based on one research report.   There's a lot of closed source java code 
out there, I suspect most of our users are closed source.  I don't know 
exactly how many compute nodes our users have, but it's 100's to 1000's, 
we seldom hear from them, maybe a patch here or there, then you don't 
hear from someone for years, and then you receive a patch.  These users 
don't advertise they're using our systems either.

Some feedback, we preserve context within Executor threads.

AccessController scalability and performance is very good, we carefully 
capture and re-establish security contexts in Executor threads.

AccessController::getContext() is 0.5% of system load, with no 
scalability issues.

AccessController::doPrivileged() is 2.3% of total cpu load, with no 
scalability issues.

There are no other security  calls on the list of hotspots, unless you 
include Class.getProtectionDomain, which is 0.2%

Like I've mentioned previously, our policy provider is highly scalable 
as is our SecurityManager implementation.  Our policy providers decorate 
functionality onto each other:

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java

It's a shame that SecurityManager is crippled on Loom's virtual threads, 
I was looking forward to using Loom for blocking network connections.  
Oh well, scratch that Idea, we wouldn't be able to make TLS connections 
with them.  I was hoping Loom would reduce memory consumption, but then 
I haven't read enough about it.  We consume a lot of threads, one of the 
thread factory's at least set the thread memory to a lower value than 
default to save memory. Is Loom is designed to run small rapidly 
completing non blocking tasks?

The performance assumptions made by Ron only apply to the unloved policy 
provider included with Java.  The Sun file policy provider 
implementation is a toy designed to get people started, no tooling, no 
dynamic permission grants, it was really only there to provide hooks for 
customization, applets maybe?  Sorry, I have to admit, I've never 
written an applet.  The second constructor added to ProtectionDomain in 
Java 1.4 added support for dynamic policy grants, but it was not 
implemented by Policy file, it was done for a reason however.    I mean 
it was designed when Sun Sparc servers had 4 to 8 CPU's, and x86 was 32 
bit single cpu, unless you spent big on Unix hardware.  Sun policy file 
has only had some very minor updates since, it has a blocking cache, yuck!

Our policy cache is immutable after publication. Mutable state is not 
shared among threads in our policy providers. Our dynamic grants are 
removed after the downloaded code is no longer required, our dynamic 
policies are self populating and self cleaning.  They also operate under 
principles of least privilege. We can also have a common policy file, or 
even a policy network service for policy (just decorate it on top of a 
minimum set of permissions required to get you started).

This is far less complicated than people are making out, it's not atomic 
physics.  Loom seems far more complicated than SecurityManager.  Policy 
features are added using policy decorators.  After you look through 
these implementations, you will see it's not that complex.

Also I'm pretty sure a cluster of compute nodes with JVM's is probably 
going to be called a server.  Ron, your assumptions don't apply to our 
use case, they apply to Sun File Policy provider.

When  Ron writes that SecurityManager is disabled on the common pool and 
Loom's virtual threads, I hope he means that these threads have no 
privileges, rather than all privileges?  There is some documentation on 
the common pool regarding SecurityManger, but little on Loom's virtual 
threads.  Can someone point me to a reference to security documentation 
on these features please?

> Security Manager is not a central component for securing trusted 
> server-side code, a good thing, too, because few systems use it and it 
> doesn’t defend against some of the most common and dangerous exploits. 
> In fact, the Security Manager is already crippled on the common pool 
> <https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html> 
> (and on Loom’s virtual threads 
> <https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable)>) 
> because setting up appropriate security contexts would defeat the 
> performance requirements of those constructs, and using it with 
> |CompletableFuture|s or any asynchronous (or “reactive”) context 
> requires the developer to carefully capture and reestablish 
> <https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/security/AccessController.html> 
> security contexts as operations travel from one thread to another.

If we disable Java serialization, we don't use XML, we validate 
invariants in our constructors and design for failure atomicity, we 
design to encapsulate, we avoid shared mutable state as much as 
possible, use immutability, we check third party libraries for security 
vulnerabilities, we perform static code analysis and we are running code 
using the principle of least privilege, we use the latest available 
TLSv1.3 cyphers and disable earlier versions.  Do you believe we are 
still vulnerable to these most common and dangerous exploits?

Perhaps we are still vulnerable to unknown or zero day exploits?

It is my opinion that removing the principle of least privilege will not 
improve the security of our software, but rather degrade it.  But then 
Java hasn't had a good reputation for security in recent years, thanks 
to Serialization, granted OpenJDK has done a lot to swat bugs as they're 
discovered in recent years, it will take a little more time to build a 
good reputation.  Personally I wouldn't be removing SecurityManager, I'd 
be addressing the issues and cleaning it up so programs can be run with 
principles of least privilege, I know it's not perfect, but nothing ever 
is, but it should improve with time, if it's not neglected and replaced 
if needed.

https://en.wikipedia.org/wiki/Principle_of_least_privilege

Maybe Unix sockets will provide a performance boost, Sockets are our 
major hotspot at 42.5%

https://pfirmstone.github.io/JGDMS/old-static-site/images/River-internet_mahalo_randomStressTest.PNG

I guess you now have a use case for what SecurityManager is capable of.

It's a shame it took SecurityManager's proposed removal for you to 
discover it has practical application.   You are right on one respect, 
not enough people take security seriously.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210506/986c5f1a/attachment.htm>