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

David Black dblack at atlassian.com
Tue May 18 22:06:34 UTC 2021


On Tue, 18 May 2021 at 22:24, Ron Pressler <ron.pressler at oracle.com> wrote:
>
>
> > 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
> on.

To be honest this still comes off as rude to me but at least you
aren't top posting and have explained why various things have been
left out.
Additionally, thank you for engaging with my emails. My point in
responding isn't to debate you but to ensure that a view is registered
& when it seems that things are left out it seems odd to me.

> >
> > 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
> system.

I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.


-- 
David Black / Security Engineer.



More information about the security-dev mailing list