SecurityManager environments

[Alan Bateman]

On 07/04/2017 03:54, Robert Muir wrote:

> :
>
> Because of these problems, if you are a server-side app, even if you
> understand this stuff and want to do the right thing, its really hard
> to avoid simply granting all kinds of horrible permissions globally to
> all code. In my experience the worst problems are the internal api
> usage issues, so it would be nice to "give jigsaw a chance" to see if
> it makes the situation better. SecurityManager is really great if you
> want to prevent common security issues such as directory traversal,
> but its too hard for a server side app right now.
I agree with most of what you said in this mail. On "common java 
libraries don't care about this stuff" then I think part of it is that 
the security manager is not enabled by default so it's a completely 
different mode of execution and so rarely tested by many library 
maintainers. Also to get the permissions right requires understanding 
each of the privileged operations that the library might need to do and 
putting that code in a privileged block so that the library can be 
granted the permission rather than to everyone.

On your gripes with default policy, the "bogus crap" as you termed it 
:-). It grants read access to a number of system properties and allows 
applications to bind to ephemeral ports, that's it. It used to grant 
"stopThread" (for compatibility reasons detailed in the comments) but 
this is no longer the case in JDK 9.

It may be that this thread should move to security-dev as that is the 
right place to discuss usability and other issues with the security 
manager.

-Alan.