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
