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

[Peter Firmstone]

On 6/05/2021 9:46 pm, Ron Pressler wrote:
>
> 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.


Static policy, terrible performance, no scalability at all, and the fact 
that you continually have to edit policy files manually, and there's no 
auditing tools?

Ha ha ha. :)  It's complicated, ha ha ha, it hardly works!  Why would a 
developer spend time writing concurrent code, then turn on security and 
slow their hard work to a crawl?  That's why they simplify it and bypass 
the policy.

No, complexity is not the problem.

It was a good design for 1997, but the java code it's written in is also 
from 1997 with little maintenance since.

For shame.

 From my observations, the native code in AccessController is scalable 
and performant and has little overhead, someone has done some very good 
work there, that has to be more recent.   This is a very good piece of 
work, very good indeed.

Sorry, I had to point out some truths.

My static policy (as stated previously there is a dynamic policy also) 
is a direct drop in replacement, you could ship with that, it would be a 
start.  You could even remove the Java policy implementation and I can 
make my policy implementation available on Maven.  It's AL2.0 licensed, 
I did look at donating it some time ago.   The code has provenance, I'm 
not the sole author, I can only donate parts of it under GPL2.0

I can also donate the profiling tool.

The thing is, if it was performant, people would stop switching it off, 
and if there were tools to handle policy complexity, then they will 
start using it, they have to use it for Principal permissions.

Here's what OSGi does, they associate permissions with modules, to 
reduce complexity:

https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html

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