<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Peter,</p>
<p>This is a similar use case, we are using trusted code also, but
we are preventing unauthorized access to sensitive data. I think
they will discover there are many use cases like this and there
will be many existing deployed systems that are not on github or
wherever they've obtained their figures from that will break as a
result. It's an API that is used in such a way that if your
application makes use of it, shotgun surgery must be prescribed
to remove it, and there will be code that people don't have
source code for that will just break and that's it.<br>
</p>
<p>It's about access control, not applets or untrusted code.<br>
</p>
<p>@Ron, please stop deliberately conflating access control with
untrusted code and security! <br>
</p>
<p>@Ron Please stop pretending it doesn't work or that it requires a
physics degree and a billion dollar budget, it's just code, maybe
you should investigate and try to understand it how it works
before disregarding it.<br>
</p>
<p>Just in case you anyone missed it I've attached it again, it is
easy to comply with principles of least privilege using a tool to
generate policy files, then edited, which also happens to provide
you with an audit of every access check and you do this prior to
populating it with sensitive data.</p>
<p>It's all about access control and it's an established api, which
you rightly point out has been with the platform a long time, so
there will be an accumulation of uses people aren't aware of.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone</pre>
<div class="moz-cite-prefix">On 6/05/2021 1:02 am, Peter Tribble
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEgYsbE+=m98mWY1c8-PfHkb4ymTED0uq-KiB33vjpfpOgN_cA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 5, 2021 at 2:13
PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com"
moz-do-not-send="true">ron.pressler@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 5 May 2021, at 05:04, Peter Firmstone <<a
href="mailto:peter.firmstone@zeus.net.au" target="_blank"
moz-do-not-send="true">peter.firmstone@zeus.net.au</a>>
wrote:<br>
> <br>
> A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH
ANY java.* package namespace API'S THAT MAY BE AT RISK OF
LATER REMOVAL IN YOUR API, java.* API's ONCE REMOVED CANNOT
BE REPLACED. IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED
IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE
WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER
BACKWARD COMPATIBLE API EVOLUTION.<br>
<br>
Any API has a non-zero risk of removal after decades of use,
and that risk is commensurate with its level of use. I think<br>
this is always true, and that everyone already knows that
and finds that acceptable, because it’s better than any
other<br>
alternative. In this particular case, we’re discussing the
removal of an API after three decades of use, with under
0.1%<br>
of codebases making use of it. <br>
</blockquote>
<div><br>
</div>
<div>It appears that my employer's codebase is in that 0.1%.<br>
<br>
</div>
<div>I've looked around the JEP, and your article, and it
isn't clear to me if there's<br>
</div>
<div>a viable alternative to a Security Manager for us. We run
server-side code,<br>
</div>
<div>including a commercial library, and simply need to ensure
that its behaviour<br>
</div>
<div>remains within defined limits. For our own code, we know
whether a file or<br>
network access is legitimate, because we can add the
appropriate checks to<br>
</div>
<div>the code. For this 3rd-party code, we simply install a
security manager before<br>
</div>
<div>calling it and uninstall it afterwards. We can't modify
the code; we can't implement<br>
</div>
<div>a sandbox at the system level (we do anyway, but the
point is that we need to<br>
</div>
<div>impose conditional access controls depending on which
java code is running).<br>
<br>
</div>
<div>We have no particular tie to the existing APIs, but the
ability to apply sufficiently<br>
</div>
<div>fine-grained permissions to sections of code is one that
has value to us.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
> <br>
> Got any example best-secured systems?<br>
<br>
I would hope that Apple's, Amazon’s, Google’s and my bank’s
systems, many of which are Java, are secure.<br>
<br>
> <br>
> I think we are talking past each other here. You keep
talking about untrusted code, which sounds like applets to
me. I've read and still have a copy of Li Gong's book,
applets were only one of the considerations. I am talking
about authorization and access control. We use and develop
distributed or p2p systems, we don't allow untrusted code to
run at all, never ever, that's a dumb idea, so lets stop
talking about untrusted code, we don't use that. We do
utilize dynamic downloaded code from others and use dynamic
class loading, we verify this prior to loading. We check
it's authorized to run before running it. Again I repeat,
we do not run untrusted code, that would allow an attacker
to cause denial of service etc, the JVM has no control over
badly behaving code.<br>
<br>
The whole design of the security manager as a
“path-dependent” deep sandbox is built around untrusted
code, hence<br>
all the stack-walking and doPrivileged. Trusted code means
assumed not to be malicious. As such, what you want to
protect<br>
against is vulnerabilities. Since you don’t know where they
are, you place the entire application in a sandbox that’s<br>
both more airtight and less complex than the Security
Manager. That is, in fact, how most people do it.<br>
<br>
> <br>
> Of course Java is "able" to do access control, it's
well documented, I have working examples. No security
defense is 100% effective, if you look at the history of
defenses, they continue to evolve. Just because
ObjectInputStream was a huge security hole, it didn't inject
an unprivileged ProtectionDomain onto the stack, which would
have stopped a number of deserialization gadgets.
ObjectInputStream runs as privileged code, tut, tut, tut!
Perl taint mode anyone?<br>
<br>
We are not talking about authorisation or access control.
We’re talking about the Security Manager’s design and
implementation<br>
which is about code domains and stack-dependence.
Serialisation’s security is one thing and the Security
Manager is a whole other<br>
thing.<br>
<br>
> <br>
> Java 6 introduced a security feature where an object
will not be constructed if Object's constructor is not
called, so that invariants must be satisfied before object
creation. Java Serialziation bypasses this. Prior to Java
6, objects could be left in a partially constructed state
and obtained via a finalizer attack.<br>
> <br>
> Besides, serialization whitelists don't protect against
denial of service, so why have them at all if you using
trusted systems and TLS connections? Java Serialization
should never be used to process untrusted data, because it
doesn't and cannot validate invariants until after objects
are constructed which is too late. As soon as you implement
Serializable, all the effort you put into defensively coding
constructors can be bypassed. So why code defensively at
all if we leave a back door wide open anyway? All code is
trusted now right, soon we can make sure all connections are
secure, so we don't need to worry about input validation
anymore either right, because the users are trusted now too?
Maybe we should just whitelist the classes allowed to run on
the JVM and not worry about coding defensively? Sounds
silly, well that's how it sounds to me, just thought I'd put
it into perspective.<br>
> <br>
> Java Serialization still compromises the security of
the JVM because it doesn't prevent object creation if
invariants aren't satisfied, the vulnerability is still
there, and future attackers will find a way take advantage
of it for that reason.<br>
> <br>
> It is clear that no further progress will be made in
this matter and I will simply have to live with the
consequences. Stick a fork in me, because I'm done.<br>
<br>
You are conflating the Security Manager with security. A lot
of security work has been going on in the JDK for the past
few years <br>
(and will continue for as long Java exists), but not in the
code-protection-domain-sandbox known as the Security
Manager.<br>
<br>
— Ron<br>
<br>
</blockquote>
</div>
<br clear="all">
<br>
-- <br>
<div dir="ltr" class="gmail_signature">-Peter Tribble<br>
<a href="http://www.petertribble.co.uk/" target="_blank"
moz-do-not-send="true">http://www.petertribble.co.uk/</a> -
<a href="http://ptribble.blogspot.com/" target="_blank"
moz-do-not-send="true">http://ptribble.blogspot.com/</a></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>