[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

On 6/05/2021 9:46 pm, Ron Pressler wrote:
> Most performance issues have to do with the stack walking at the core of the Security Manager’s design.

I disagree, unless you can provide /evidence or context, I have not seen 
any evidence for this, I've done a lot of performance testing on the 
security infrastructure over the last 10 years.

When SecurityManager is enabled, with the default policy provider, 
synchronization in PermissionCollection::implies checks are a huge 
scalability bottleneck.

I have not seen any performance bottlenecks from stack walking in hot 
spots in my tests, unless you call 2% a hotspot.   Although I do allow 
for hotspot to warm up to make optimisations.  Are you talking 
micro-benchmarks?  Prior to hotspot optimization?

Do you have any performance tests results I can look at?

>> 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?
> It is meant to run a great many concurrent tasks performing blocking operations (although they translate to non-blocking I/O once
> they reach the OS). Obviously, many of those will be short-lived, as you’d be able to spawn a new thread just for the purpose of,
> say, doing one HTTP client call.


Ok, this does sound useful.

>> 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.
> Trying to convince people, at this point, after twenty five years that the Security Manager isn’t complicated after all might
> be too little too late. We know that, for reasons good or bad, very few people opt to use it, and that most who do, do it
> incorrectly. If, twenty five years from now, it turns out that Loom’s record is similar, I have little doubt that a similar
> proposal would be raised then.


That's not my concern, you made the argument it was impossible, that 
there were no working implementations, I think you concede now that 
isn't the case, therefore job done.  You have a vested interest in its 
removal, so you attempt to downplay the impact it will have on Java 
developers, I have a vested interest in reducing the maintenance burden 
I have too.

My concern is software compatibility.   The newly proposed API's only 
replaces existing functionality, and it does so in a way that is not 
backward compatible.  It offers no new features, it only lessens 
OpenJDK's maintenance burden, while causing a huge maintenance burden 
for downstream projects.

The proposed changes not only impact those who use SecurityManager, but 
will also impact anyone that uses the current sign in mechanisms, and 
use the Subject for TLS connection authentication as well as Kerberos.

Shotgun surgery and breakages go far beyond SecurityManager alone.

Why not simply document it instead as I have suggested in my reply to 
Alan and treat the bugs differently to reduce maintenance cost?

No new API's are needed then.

> That is correct. Here is where this is mentioned for ForkJoinPool: https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html
>
> And here it is for virtual threads (the JavaDoc is still a WIP):
> https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable)


Can I use doPrivileged blocks with context, or will they be 
innefective?  If yes to the former and no to the latter, then it's great 
these threads have no permission by default.

Just trying to work out if I can use it with secure network connections?


>
>> 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.
> There is nothing wrong with the principle of least privilege. Experience, however, has shown that relying on different code
> having different permissions *in the same process* is not a good strategy. After twenty five years of Security Manager with little
> use and less still proper use, and with most of the ecosystem not supporting this mechanism anyway so even if improvement were justified
> it would take years until people could enjoy it, increasing investment in it would be, in my opinion, throwing good money after bad.


Experience with poor or incomplete implementations has shown that.  You 
have to admit then, that you have zero experience with a good 
implementation.

It's just access control, you are mistakenly still thinking about 
sandboxes.   In the sandbox model, the sandbox is the be all and end all 
of security, the sandbox is supposed to present a safe and impenetrable 
api, in the cheese model, access control is just one layer of cheese 
with holes.  Because nothing is perfect, it's better to have multiple 
layers of security, as it reduces the chances of things like gadget 
chains succeeding, rather than a be all and end all wack-a-mole 
whitelist approach that seems to be popular of late.

https://securityandpeople.com/2017/07/human-errors-in-cyber-security-a-swiss-cheese-of-failures/

Anyone can use JGDMS to enjoy it now, little investment is required, the 
work is done.  It also takes the pain out of implementing TLS 
communications as well, including preserving the Subject across JVM's.

https://github.com/pfirmstone/JGDMS

It supports Maven and OSGi, so you can dynamically download libraries 
and automatically assign permissions.  Haven't implemented support for 
Java modules yet, as we still compile on Java 8, although funnily enough 
we use later TLSv1.3 cypher suites.

Oh, that reminds me OSGi also implements SecurityManager and has dynamic 
permissions, it can revoke as well as grant permissions, are you aware 
of it?  It uses a different mechanism though, because it pre-dates Java 
1.4, I don't recall the implementation.

>
>> 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.
> Security and the Security Manager are not the same thing,

Agreed, but your statement is not relevant to the points I'm making 
here, you are still thinking about sandboxes, instead of access 
control.  Sandbox whitelists is wack-a-mole, so is white listed 
Serialization without atomic failure input validation. Maybe it's not 
that people don't take security seriously, it's that they think white 
lists are an appropriate form of security, without authentication and 
validation, they are not.  Same problem with the sandbox.  Access 
Control is still useful, when it's not treated as the front line of 
security, but a more rearward layer that is expected to have holes, 
because it has limitations, so we instead depend on a armory of defense 
layers, each with flaws, that we try to manage.  The Cyphers of the late 
90's are no longer in use, and neither is the sandbox.

>   virtually none of the security work in the JDK in the past few years
> took place in the Security Manager,

Because Serialization is not failure atomic, is performed by privileged 
system code and developers had open network ports without authentication 
that an attacker could intercept and use gadget chains to take over the 
JVM, I don't see how this is relevant to access control for trusted code 
and trusted users. There were similar problems with XML.  This is why 
whitelists and whak-a-mole is not security either, also why I think 
whitelist serialization will come back to bite again, because people 
using whitelists think they can process data, without proper input 
validation.  What makes it works is it's a separate concern, it breaks 
object encapsulation.

There should be a command line parameter to disable Serialization, in 
such a way that it cannot be enabled at runtime.

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