RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Will Sargent will.sargent at gmail.com
Sun Sep 16 19:37:21 UTC 2018


> The security manager is legacy these days and I think we need to
figure out a plan how to deprecate and eventually bury it.

I don't know of any research or papers that explicitly say that
SecurityManager is "legacy".  I did some research into this a while ago,
and while SecurityManager has some major flaws, I don't know of any other
way to sandbox a Java application.

I went through two sample projects and found a way to use Byte Buddy to
disable SecurityManager so that it could not be disabled:

https://tersesystems.com/blog/2015/12/22/an-easy-way-to-secure-java-applications/

https://tersesystems.com/blog/2015/12/29/sandbox-experiment/

https://github.com/johnlcox/sandbox-runtime

If there is a way to do this without involving the security manager that
would be great -- likewise, if there's any docs on how it's just not up to
the task, that would be good too.

Thanks,
Will Sargent.


On Fri, Sep 14, 2018 at 6:22 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/09/2018 13:46, David Lloyd wrote:
> > :
> >> There are essentially two main parts to this change:
> >>
> >> 1. Deprecation of System.s[etS]ecurityManager()
> > We (JBoss) use this method to configure some things at run time (like
> > customizing the Policy) before installing our security manager, so
> > this would be not so great for us.
> The security manager is legacy these days and I think we need to figure
> out a plan how to deprecate and eventually bury it. I have no idea how
> many releases or years that might take but the proposal here is a
> profitable first step. It's easy to imagine follow on steps where the
> default changes to not support the security manager without some opt-in.
> Yes, this will be disruptive for a number of usages but there is lots of
> time to look for solutions to the issues that people are using the
> security manager for today - for example we've seen several cases where
> people set a security manager because they lack hooks to prevent plugins
> from doing things (plugins or tests calling System.exit comes up
> periodically for example).
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180916/b6063dff/attachment.htm>


More information about the security-dev mailing list