JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Tribble]

On Wed, May 12, 2021 at 10:22 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 12 May 2021, at 21:46, Peter Tribble <peter.tribble at gmail.com> wrote:
> >
> > We're (partly, at least) in that group. We can't block the access from
> outside
> > the JVM (and we are containerized with restricted permissions already)
> because
> > some accesses are legitimate - something outside the JVM doesn't know
> when
> > the JVM is executing a particular piece of code, so we toggle the
> Security Manager
> > on and off depending on context.
> >
> > And here's the thing; there isn't really anything in the proposal that
> addresses this
> > use case, or offers an alternate way forward.
>
> Could you describe what your use-case is in the most precise way you can?
>

Let me give a concrete example:

Parsing and rendering a PDF file that may contain references to fonts or
other resources.
We know exactly where the files are installed, so wish to allow the
rendering routine access
to the fonts it will need. But not to any other files, and not (normally)
to network resources at
all. Note that we trust the code, but not necessarily the document it's
parsing. (Although the
document itself may be perfectly well formed - document formats often allow
embedding
references to 3rd-party objects, undesirable as that may be.)

There are a range of such issues in document parsing and rendering. And
unfortunately, the
good libraries for this task are proprietary so we can't modify them to
apply the restrictions
we're after. The (server-side) application does need access to files and
network resources at
other times; it's only when it goes into the rendering step that we lock it
down, and unlock it
once done.


> That there are useful applications of the Security Manager out there is
> certain; the same
> was certainly also true for Applets. The problem is that the total good
> that the Security
> Manager contributes does not justify the high cost of its maintenance. The
> more we can
> understand what people use it for and how, the better we are able to judge
> how much we
> should afford to put into some simpler replacement. Having said that, it
> is certainly
> possible that some of the millions of Java developers out there will be
> disappointed. We
> try to direct our resources where they’d do the most good, and when we
> can, try to find
> a solution for small groups that are harmed by such budgeting.
>

I appreciate the reasoning here, and thanks for letting us try and describe
some our
use cases.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210512/f251bc38/attachment.htm>