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.firmst...@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:
http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup
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.
