[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Ron Pressler ron.pressler at oracle.com
Tue May 18 12:24:18 UTC 2021

> On 18 May 2021, at 07:10, David Black <dblack at atlassian.com> wrote:
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.

This isn’t a debate forum. We’re trying to collect information, not 
to convince every last person. I respond to what I think I can comment 

> I am not trying to be rude but I would like to ask what is more expensive -
> 1) auditing 1,000,000 lines of code - with active development on going
> 2) re-architecting an application so that the main process ?cannot?
> make new connections after a certain point (preventing new FDs from
> being opened) & making external connections from another process which
> has operating/configuration/other restrictions on it to prevent it
> from talking with sensitive network locations
> 3) examining all known locations using a security manager in a
> non-enforcing mode or as you noted - the Java Flight recorder & fixing
> all known currently existing locations
> 4) ^ 3 but you use a security manager or something that lets you make
> decisions about connections/$things such that you can block in
> addition to monitor things

I happen to think that the most cost-effective thing would be to assign
the entire trusted process the minimal permissions it requires, to monitor 
it for suspicious activity with JFR, and to invest the effort required to
maintain the Security Manager in security measures that most people might
actually use. Is that 3? The question of whether or not it’s worth it to go
from 3 to 4 depends on the added cost vs the added benefit, compared to all
other options. I happen to think it’s not worth it, but the relevant 
maintainers might well consider some inexpensive building blocks for those 
who think differently, and wish to construct a code-origin based permission 

— Ron

More information about the security-dev mailing list