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.
