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

Sat May 22 11:43:26 UTC 2021

It is precisely because security is more important now than ever and both the threat environment and
security measure landscape are changing that this proposal is important. There have been several good
suggestions brought up —- like platform-independent access to platform-specific defences —- as well as
various security challenges, but none of them can be tackled with the vigour they deserve when the
resources of the security team are invested in maintaining a very costly mechanism that was not only
designed for a different threat environment, but, more importantly, isn’t deployed by the vast majority
of Java users, even those that care deeply about security.

All JEPs are usually submitted toward the *end* of a long deliberation process, and are intended to gather
information that might have been overlooked, so the nothing could be further from the truth that this is
done “without hesitation”. Indeed, no such new information has come to light yet.

We believe that the principle of least privilege would be better served without the Security Manager, 
and that security overall be improved with mechanisms that people actually use, some are already in place 
but will continue to improve with more resources available, which include, but certainly aren’t limited
to, strong encapsulation which was turned on in JDK 16, remote JFR streaming also added in that version, 
access control which will be separated from the Security Manager, and OS-level sandboxes. 

When taken over the entire ecosystem, it is our informed opinion that the number of attacks actually stopped 
by the Security Manager over the past decade does not justify effort it costs, while other mechanisms do.
It doesn’t even serve as a deterrent to attacks, because attackers know that it is rarely installed. Therefore, 
to improve security we must shift resources from efforts that, however intrinsically effective, don’t have the 
intended and much needed impact in the security of the Java ecosystem to those that do and will.

- Ron

> On 22 May 2021, at 11:58, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> Hello,
> 
> I have to agree with Peter here, we do remove a very valuable asset of the JVM platform. It might not easy to be used and not the most popular technology, but after all it was in the DNA of Java. In this JEP/Discussion there is not a single hesitation  to remove it. Please tell me you tried to find maintainers?
> 
> This whole discussion about using only secure libraries really makes me wonder if you know the realities of modern applications with hundreds of dependencies and the state of those, like there is still no easy way to limit XXE in upstream xerces. (Or Have you ever tried to set FSP on a Transformer?), limit deserialisation, restrict url handlers, impersonate Users (local and remote filesystem), run chroot child’s or pass credentials over named pipes. All mechanisms which are easier to do in other programming environments. There is a big hesitation to even offer those platform specific features.
> 
> I do hope the result of this discussion really is a set of new replacement technologies which allow to use least priveledge methods from the operating environments (be able to run as a different User token, drop permissions, use chroot/jail, fsuid, capsetp,setgroups and other impersonation methods) as thread scopes. Also facilities for multi-process solutions (named pipe servers, shared memory) might help with doing proper low priveledged architectures in the future (in addition to stuffing everything into rootless containers)
> 
> But more importantly we do need to get a handle on Defense in depth for libraries. LFI and Remote connections is a big part of that, but not limited to it.
> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Peter Tribble <peter.tribble at gmail.com>
> Gesendet: Saturday, May 22, 2021 11:11:43 AM
> An: Ron Pressler <ron.pressler at oracle.com>
> Cc: Peter Firmstone <peter.firmstone at zeus.net.au>; David Black <dblack at atlassian.com>; Alan Bateman <alan.bateman at oracle.com>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
>  
> On Sat, May 22, 2021 at 2:12 AM Ron Pressler <ron.pressler at oracle.com> wrote:
> Let me be very clear: the proposers of this JEP, some of whom have worked on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not harm Java’s security, but considerably
> improve it, as do the maintainers of other platforms who have decided to either not try to offer security
> through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed
> by security experts, both those working on OpenJDK and outside it.
> 
> I understand that maintaining the Security Manager is a burden. I understand the argument that not
> having the Security Manager would allow resources to be better deployed elsewhere. Yet here we're
> only seeing the one side. It would be good to be able to see the ways in which Java's security would
> be improved by this JEP, because at the moment we're having to take that on trust.
>  
> While I seriously hope you don’t actually believe a decision was made before publication, it is also obviously
> true that this wouldn’t have been proposed in the first place without *a lot* of thought, study and discussion.
> The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding
> fault with it are low. It wasn’t put up after someone just had an idea. It is, therefore, not entirely 
> surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less 
> time to think about it, but I can’t seem to steer your arguments in a direction that’s relevant to what is actually 
> the issue.
> 
> I understand you’re invested in the Security Manager and that its removal would impose real costs on you. I am even
> willing to believe that you actually believe that, despite what studies show, despite what experts say, despite
> what the developers of Java say, despite what the developers of *all* other mainstream software platforms with 
> an emphasis on security, both new and old —- from .NET to WebAssembly —- have concluded after decades of experience, 
> that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you’re right 
> and those others are wrong, but please accept that we all want to improve Java’s security, we just disagree with you 
> on the best way to do it.
> 
> Yes, additional security measures, whatever they are, would provide additional security. But if the choice is 
> between measure A and measure B -— you *can’t* have both —- you pick the one that is *more* effective per cost.
> 
> And yet the proposal in front of us is to remove measure A, which *will* reduce security for those using it.
> Where's the proposal for measure B, so we can evaluate whether the tradeoff between A and B is beneficial?
>  
> None of your arguments so much as glance in that direction, and they don’t acknowledge the fact that Java security 
> would be hardly affected by the Security Manager’s removal even without better protection elsewhere for the simple 
> reason that it is hardly ever installed, including on the most security-critical applications, whose defences 
> apparently aren’t so feeble even today. In any event, if the question is, do we want a perimeter fence and security 
> cameras *XOR* locks on all room doors, the argument that they provide security through different mechanisms so we 
> should have both completely misunderstands the question. I am also confused by your point about multi-user
> applications. Of course different users have different access, but surely you are aware that very few applications
> do that using the Security Manager, which isn’t needed —- and is rarely used -— for that purpose.
> 
> Short of making relevant arguments, I would urge you again to focus on suggestions to reduce the harm this proposal 
> would cause you.
> 
> — Ron
> 
> 
> 
> > On 22 May 2021, at 00:17, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> > 
> > I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy.
> > 
> > Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so securely again.
> > 
> > 
> > On 21/05/2021 11:06 pm, Ron Pressler wrote:
> >> 
> >>> On 21 May 2021, at 12:52, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> >>> 
> >>> It's quite clear this will be pushed through anyway,
> >>> 
> >> No, not *anyway*, but given the fact that the community consists of millions of users, this
> >> proposal has been well-publicised,
> > 
> > 
> > I discovered the proposal on the 11th of the May on a mailing list I was subscribed to and I almost missed it.   Yes, it will be pushed through regardless, clearly the decision was made before publication.   Everyone saw applets coming, if the developers were serious about supporting applets, they would have designed a stripped down subset of Java, a JVM specifically suited that task which, didn't include things like XML or serialization.
> > 
> > Just think, Applets were killed because of their atrocious security.   How ironic.
> > 
> > 
> >>> The granularity is not arbitrary, you said by class, which is incorrect.
> >>> 
> >>> Granularity is by a combination of one or more of the following:
> >>> 
> >>>     • ProtectionDomain
> >>>     • CodeSource
> >>>     • Code signers
> >>>     • ClassLoader
> >>>     • Principals.
> >> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
> >> (certainly not in code you can’t modify). In fact, ProtectionDomain is defined as “a set of classes,”
> >> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
> >> aims to address, and that is one of the Security Manager’s most defining features.
> > 
> > It may be possible to assign a ProtectionDomain, to a single class, but that doesn't make your assertions correct, you should be quoting common use cases, I have never seen an example of assigning permissions to a single class, besides, it requires a dynamic policy to do that, and Java doesn't have one by default, so you can't use PolicyFile to assign it permissions.   Maybe you could use it to encapsulate ObjectInputStream with no permissions, then no one could grant it permissions, so that would be useful for Security.  It doesn't change class resolution or visibility. But OpenJDK didn't do that, why not?
> > 
> > 
> > What use case would there be to assign a ProtectionDomain to a method?
> > 
> > Just use a permission check in the method, or wrap a sensitive class with a decorator before publication:
> > 
> > https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$ 
> > But these are corner cases.
> > 
> > More useful cases are for isolation, such as JEE.
> > 
> > 
> >> 
> >> Restricting access by principal at the application level does not require the Security Manager, so that
> >> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
> >> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.
> > 
> > 
> > I guess your use case is a desktop application running in a single process?
> > 
> > What about a multi user server application running in a single process?   Now we have to spawn multiple processes for each user, that's hardly efficient or performant is it?
> > 
> > 
> >> 
> >>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
> >> The pain is that the high cost of maintaining the Security Manager comes at the expense of
> >> other security measures that, we believe, provide far more security value to the Java ecosystem
> >> as a whole.
> > 
> > 
> > Such as?
> > 
> > 
> >>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
> >> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
> >> of applying it at class granularity yields its best application.
> > 
> > 
> > I agree that there's little value for class granularity, but you are applying a corner case that although possible, is never applied in practice, and applying it with a broad brush, then using it as an argument against, please stop making this false assertion.   Just because you can do something, doesn't mean that you should.   Just because you can walk in front of a passing train, doesn't mean you should sir.
> > 
> > There is however a significant benefit for applying the principle of least privilege.
> > 
> > It can be assigned to Principal and Code signer granularity, that's actually quite coarse grained.  It's very flexible, unlike white listing Serializable classes.
> > 
> >>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
> >> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
> >> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
> >> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
> >> module system’s defences -- and we believe investing in them has a better security ROI overall.
> > 
> > Don't be rude.  These are not alternatives, some are complementary, but not one provides the missing functionality.
> > 
> > And yuck, serialization, XML, vulnerable components should have been given un-privilged ProtectionDomains, so they couldn't do anything privileged while on the stack, like Perl Taint mode.   Or better yet alternative implementations created that practice data hygiene.
> > 
> > Java Serialization is a good example of good money thrown after bad, that has a far greater development cost.   Why did you (yes you OpenJDK) make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate library, let people that use it download it, then the platform isn't made insecure for those who don't want it, this is a good use case for your new module system.
> > 
> > Once SecurityManager is gone, attackers will likely be able to bypass your feeble protections, such as whitelisting classes to be de-serialized; they only need to find a way to change a property prior to initialization, the first use of ObjectInputStream, which is quite easy if an application doesn't use it.  In future developers who don't use Java serialization will need to make sure it has been initialized so it can't be used as an attack vector, who will remember to do that?
> > 
> >>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
> >> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
> >> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
> >> don’t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
> >> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
> >> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.
> > 
> > 
> > Library's don't need to be instrumented for it, the Java platform is already and provides the necessary protection for network connections, file access and class loading for example.
> > 
> > 
> > - Peter.
> > 
> 
> 
> 
> -- 
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/