JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

Thanks Alan,

Concurrency is difficult too, but Java has gone a long way to addressing 
this with concurrency libraries that make the task seem like child's 
play, compared to using Java 1.4 language constructs.

On 31/05/2021 5:59 pm, Alan Bateman wrote:
> On 31/05/2021 08:11, Peter Firmstone wrote:
>> :
>>
>> I think also that many more people are using SecurityManager than 
>> OpenJDK realises, and they're not using it how OpenJDK recommends 
>> either, (AllPermission granted to trusted code, and sandbox untrusted 
>> code model of Applets is not how we use it) people are using POLP, 
>> it's just that no one reports back to OpenJDK because they are only 
>> editing policy files, it will work with any library out there now, 
>> there's nothing to write back about.  It's pretty clear that OpenJDK 
>> devs don't use it, but they do have to manage doPrivileged and 
>> preserving context across tasks and threads.
>>
>> And there are static analysis tools in Spotbugs to identify 
>> doPrivileged bugs, but someone has recently suggested removing them 
>> thanks to this JEP?  Does OpenJDK use static analysis.  I think if 
>> you did you'd find plenty of latent bugs.
>
> I don't think the SM is approachable by most developers. I've sat 
> through several embarrassing sessions at conferences over the years 
> where a speaker attempted to get something non-trivial to work with 
> the SM enabled. More often than not they had to deal with libraries 
> that had never been run with a SM before and it was whack-a-mole to 
> get them to run. 


Yes, it shouldn't have been allowed out the door without a tool for that 
reason, it could have been avoided.    Yes, I have a tool that sorts 
that very problem, it's 500 - 600 lines of code. Just specify two 
command line arguments which are the security manager and policy file 
location, it generates the policy file, then you look at the file 
briefly, alter some permissions like network for ephemeral ports, easy, 
you now have a POLP policy file.   You do need to properly run the 
program through its use cases however, but testing is often sufficient, 
even if you don't have full test coverage it will capture 99.9% of 
permissions required, then if you tests are missing a permission, it 
indicates insufficient test coverage.  The tool will also append, so you 
can run multiple processes and user roles one after the other.

I will rewrite it in GPL2.0 if you ask me to.  The only reason I didn't 
get around to it before was it's AL2.0 and there wasn't an existential 
threat to SecurityManager API's.

> As you know, any library or framework with callbacks means careful use 
> of doPrivileged to avoid needing to grant permissions to every 
> component on the stack. You mention capturing and re-asserting 
> contexts across threads, this is just way too complex for most 
> developers. My guess is that if we had enabled the SM by default 20 
> years ago then it would be a different discussion today. This is not 
> to say that there isn't some usage, the flurry of mails here over the 
> last month does show that there is some usage. The SM survey in 2018 
> showed that there was some usage too.


Yes, so how do we start that process?  It doesn't matter if we start it 
now or 20 years ago, as long as when it does happen the outcome is 
positive, I have been coming across more and more developers who 
implement POLP or that want to.   Executors has two methods which 
decorate Runnable and Callable, but they could be placed into the 
Executors and performed automatically when tasks are submitted, when 
SecurityManager is installed.

We could give developers a choice, so loom threads are zero privileged 
by default  or are treated as doPrivileged calls with the Subject of the 
creator, so it only has one ProtectionDomain and load it with immutable 
collections of permissions, then we can use them for TLS connections if 
we want or leave them unprivileged.   It's a fair compromise, just make 
sure the callers domain has minimal privileges.  It seems to me that 
loom would be very good for blocking IO.  It only needs to be 
documented, then we will use it appropriately.

In my SecurityManager implementation, once an AccessControlContext has 
been checked for a Permission, it is only ever checked again if the 
policy is refreshed, so it's a once off which has little impact in an 
Executor pool.  It uses concurrent collections that are decorated with 
weak references, to avoid memory leaks.


>
> I can't speak for all OpenJDK contributors but Oracle contributors do 
> a massive amount of analysis and static analysis before proposing to 
> deprecate or removing anything. It's often much harder to remove 
> something that add it and I don't think anyone has proposed 
> deprecating or removing anything without a strong case.
>
> -Alan
>
>

I understand, but this is incredibly useful software when POLP is 
applied and if promoted properly with good tooling and documentation it 
addresses a lot of technological issues that are receiving much more 
attention, millions of medical records are stolen every year and 
governments not getting along as well as we'd like?

https://www.wesh.com/article/millions-of-health-records-stolen-every-year/29988160

Could Java be the answer?

It can be modified and improved, it hasn't received much love for a long 
time.

I'm sure it can be made much more friendly.   Turn it into Java's 
advantage instead, nothing else like this exists and we know and those 
that do use it, understand it very well because it's been around such a 
long time.

Peter.