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