JEP411: Restricting/logging library usages using a SecurityManager

[Peter Firmstone]

Just some references regarding Roel's original argument below:

https://techbeacon.com/security/third-party-libraries-are-one-most-insecure-parts-application

https://debricked.com/blog/2021/01/02/vulnerabilities-in-dependencies/

https://www.tripwire.com/state-of-security/vulnerability-management/managing-security-risk-introduced-by-third-party-libraries/

https://www.infosecurity-magazine.com/opinions/third-party-libraries-the-swiss/

https://auth0.com/blog/third-party-assets-security-risks-management/

It will be interesting to see how OpenJDK plans to develop new ways to 
assist developers to mitigate third party library risks.

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

On 16/04/2021 7:10 am, Roel Spilker wrote:
> Hi all,
>
> So I do get why RMI and Applets are no longer used.
>
> I also agree that the performance and usability of the current 
> implementation is suboptimal, and that configuring the security 
> manager through text files is also not that easy.
>
> But on my server application, we use libraries. And I'm very 
> interested on how they behave.
>
> I would like to log or restrict the following actions:
> - Spawning new processes
> - Unexpected file access
> - Unexpected network traffic
>
> Currently, our application sets a custom written security manager to 
> restrict or log those aspects.
>
> For example, we would block all XXE attacks by just having our 
> security manager.
>
> In JEP411 I did not find a way to do those things without a security 
> manager.
>
> What does the security group think about these use cases? Does it 
> still make sense to deprecate/remove the entire security manager? 
> Would a replacement for certain concerns be in order?
>
> Kind regards,
>
> Roel Spilker