I think it would be useful to configure the JVM to prevent loading of
untrusted (unsigned) code. This might be useful in preventing
injection attacks, where the attacker is attempting to have the JVM load
remote untrusted code.
--
Regards,
Peter
On 4/04/2025 3:45 am, Scott Lewis wrote:
There are problems with the agent approach, finalizer's must be
disabled, but there are other issues, such as replacement of
doPrivileged calls and the need to widen permission grants as everything
is on the stack.
I did consider a mode where there are no privileges unless a privileged
call h
Hello,
This are some very interesting comments in JEP 486:
Various early Java Platform features were designed around a vision of
mobile objects. They used serialization to move code and data between
JVMs, and assumed applications would enable the Security Manager to
defend against maliciously
Hi Lim,
You raise a good point about how to prevent loading unauthorized code.
I'm interested to see the responses you'll get.
I think OpenJDK was overly focused on sandboxes, applets and
serialization, instead of authorization and principles of least
privilege, where the focus should have
ual machine. We
supported it with tooling that makes POLP authorization relatively easy
and simple to develop and deploy.
https://github.com/pfirmstone/JGDMS/wiki
Regards,
Peter.
On 4/10/2024 12:32 am, Sean Mullan wrote:
We are aiming to do this in 24, but nothing is official until the JEP
Which release does this target?
I've been waiting to learn the affected Java release, so we can document
which versions of Java our software can and cannot support.
We'll continue to use Java beyond this release, but will need to
maintain our own fork, as it's not possible to build an Authori
Hmm, makes me think of Bin Chickens... Project Bin Chick (cough)
Brisbane. Not as cool as "Blowfish", but hey we've got a lot of Ibis in
here Brisbane, Aussies call them Bin Chickens.
Cheers,
Peter
On 4/06/2024 1:03 am, Volker Simonis wrote:
Hi,
What's the status of Project Brisbane? Acc
ks,
Peter.
On 8/03/2024 5:52 pm, Alan Bateman wrote:
On 07/03/2024 23:30, Peter Firmstone wrote:
Can this change be documented along with others planned in the new
JEP so these changes are easier to track?
As Sean said, JEP 411 already links to JDK-8267108 that introduced
Subject.curr
ixes), while we figure out
how to manage changes brought about by JEP411.
Thank you.
Peter.
On 8/03/2024 8:31 am, Peter Firmstone wrote:
Sent from my iPhone
On 8 Mar 2024, at 1:35 am, Sean Mullan wrote:
On 3/7/24 7:35 AM, Peter Firmstone wrote:
Good Evening,
Just noticed the comment b
Sent from my iPhone
> On 8 Mar 2024, at 1:35 am, Sean Mullan wrote:
>
> On 3/7/24 7:35 AM, Peter Firmstone wrote:
>> Good Evening,
>> Just noticed the comment below, this is a breaking change.
>> Recalling earlier discussions on this list about the removal of the
Good Evening,
Just noticed the comment below, this is a breaking change.
Recalling earlier discussions on this list about the removal of the
existing Authorization API post JEP411, it was going to be assigned
another overarching JEP.
Can we have the entire API destructed in one swift action?
eful death,
without requiring people who don't use it to be burdened by it.
--
Regards,
Peter
On 4/07/2023 1:28 am, Anthony Scarpino wrote:
On 6/30/23 4:26 AM, Peter Firmstone wrote:
On 17/06/2023 11:13 pm, Alan Bateman wrote:
On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino
On 17/06/2023 11:13 pm, Alan Bateman wrote:
On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino
wrote:
This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has
always been separate from the base module/pkg because of its dependence on a
native library. That library was rem
5 pm, Alan Bateman wrote:
On 18/06/2023 12:52, Peter Firmstone wrote:
Thanks Alan,
Personally, I would hope that nothing happens until after Java 21,
time is precious, we'll need all the time we can get.
I was hoping, that all privileged actions might be retained
indefinitely, so that we
On 23/06/2023 11:06 am, Ron Pressler wrote:
On 22 Jun 2023, at 23:50, Peter Firmstone wrote:
If you are able to share, I'd be interested to learn about challenges you had
with SM, if we one day have the opportunity to reimplement it, the lessons
might be valuable, so we can avoi
thing to gain from removing a feature whose
benefits outweigh its cost
The cost is very high. I've spent probably a year on the SM just for
jdk.jfr module.
Erik
*From:* security-dev on behalf of Ron
Press
On 21/06/2023 8:52 pm, Ron Pressler wrote:
On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
I'm just disappointed that we are being prevented from reimplementing a
replacement authorization layer in Java, without any compromise from OpenJDK
it's not possible. We at least need
On 20/06/2023 9:08 pm, Andrew Dinn wrote:
We have already provided better ways to address security concerns
Maybe the documentation hasn't been updated, I can't find the "better
ways" to do authorization, unless it's not considered a security concern
any more. But I don't feel like arguing
On 20/06/2023 9:04 pm, Ron Pressler wrote:
On 20 Jun 2023, at 06:26, Peter Firmstone wrote:
Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's
just OpenJDK is also undoing years of tested and hardened API's,
You probably meant that as a bad thi
x27;t taken it personally, everyone has their good
and bad days.
The new encapsulation improvements sound promising, if I was a young
developer, without existing software to maintain, I think I would be
happy about it.
--
Regards,
Peter
On 20/06/2023 7:33 pm, Andrew Dinn wrote:
O
orward? Then it's over and we can stop worrying about it.
There's a cloud outside and I've got some yelling to do.
--
Regards,
Peter
On 20/06/2023 1:11 am, Ron Pressler wrote:
On 19 Jun 2023, at 12:48, Peter Firmstone wrote:
For most Java developers, and Jvm users, it mea
tool can be found here, in case anyone is interested:
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
Here's are some good videos I recommend people watch, if they find Java
security interesting,
For most Java developers, and Jvm users, it means that all Java
bytecodes need to be audited and trusted, to be fair OpenJDK provide
flight recorder and other tools. The drawback of this approach, is that
Java allows dynamic code downloads, attackers will attempt to introduce
gadgets, or injec
oftware on the Java platform going forward.
--
Regards,
Peter
On 18/06/2023 10:15 pm, Alan Bateman wrote:
On 18/06/2023 12:52, Peter Firmstone wrote:
Thanks Alan,
Personally, I would hope that nothing happens until after Java 21,
time is precious, we'll need all the time we can get.
27;t your publish subscribe web
service model. It turns out everything they dreamed of was possible, it
just required time to sort it out.
Comparatively, problems with Authorization are small and simple, easily
solved.
Thank you for your time and responses, I hope what I've said will be
Curious to know OpenJDK's plans for removal of
AccessController::doPrivileged calls?
PrivilegedAction shows intent, that an action about to be executed
requires privileges.
Can OpenJDK retain instances of PrivilegedAction and
PrivilegedExceptionAction?
We can find PrivilegedAction::run in
4
--Sean
On 6/16/23 1:48 AM, Alan Bateman wrote:
On 16/06/2023 03:48, Peter Firmstone wrote:
:
As it isn't yet clear how a Subject context will be preserved across
threads in future version of OpenJDK, (currently we use the
AccessControlContext for that), for example we capture the existing
wrote:
On 16/06/2023 03:48, Peter Firmstone wrote:
:
As it isn't yet clear how a Subject context will be preserved across
threads in future version of OpenJDK, (currently we use the
AccessControlContext for that), for example we capture the existing
context, to establish TLS connections in
Release Note: Alternate Subject.getSubject and doAs APIs Created That
Do Not Depend on Security Manager APIs
https://bugs.openjdk.org/browse/JDK-8280491
Just wondering about the future implementation plans for these new API's?
The implementation depends on deprecated for removal API's in JEP
Or this, which is an example of limiting a codebase by it's SHA-384
signature:
https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L2241
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
On
These are examples of how we currently lock down the JVM, to limit
providers, policy files are generated using a tool, it may do as an
interim control measure, until something else is provided, it is of
course a deprecated feature, subject to future removal, but it may do
the job temporarily, w
Should JAAS should be renamed JAS? Java will no longer have support
for Authorization functionality, so this should be named "Java
Authentication Service" JAS right?
I'm currently working on a new Authorization framework for Java, it
works a little differently.
https://github.com/pfirmston
locking us
from developing a new Authorization framework. It's vandalism.
So after 20 years of developing Java, it's come to this.
It leaves a bad taste in my mouth.
Old man yells at cloud!
On 10/02/2023 9:21 am, Peter Firmstone wrote:
Please undeprecate DomainController interfa
using developers to remove code that we need, this is
undoing years of hard work, I'm appealing to you to minimise harm where
possible.
eg: https://github.com/apache/lucene/issues/11801
--
Regards,
Peter
On 10/02/2023 9:03 am, Peter Firmstone wrote:
Maybe I had the wrong Subject?
n if they contain no implementation, so that we may
instrument them, as we attempt to stay current with OpenJDK.
We are not asking OpenJDK to maintain OpenJDK security using an
authorization framework, we are just asking you to make it possible for
us to maintain our software's security our
We're just trying to migrate as best we can to future versions of Java.
--
Regards,
Peter Firmstone
On 7/02/2023 12:53 pm, Peter Firmstone wrote:
Hello OpenJDK folk,
SecurityManager, AccessController and AccessControlContext will be
removed in a future version of Java.
Just briefly
principle of least privilege policy generation tools
and efficient policy checking tools for authorization in place.
These allow for simple policy file generation, auditing, editing and
deployment.
--
Regards,
Peter Firmstone
On 1/11/2022 5:52 pm, Alan Bateman wrote:
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote:
You have jumped through some refactoring hoops to be able to apply the
deprecation suppression to as little code as possible .. having made such
changes, then why didn't you just make the recommended
Some additional information that may be helpful:
org.apache.river.api.net.Uri has method signatures in common with
java.net.URI, due to its development history.
The implementation was originally part of Apache Harmony which was
RFC2396 compliant (Harmony's implementation of java.net.URI)
I'm considering using one of the non parsing constructors, as Alan
points out we're currently double parsing. By the time the constructor
is removed, I'm guessing there will be a RFC3986 URI implementation in
the JDK, so we'll change to that when it happens. Or if you decide to
not deprecate
On 27/10/2022 4:26 pm, Alan Bateman wrote:
On 26/10/2022 23:53, Peter Firmstone wrote:
The change will have some performance impact, by requiring redundant
parsing.
Just thought I'd mention it, in case it hasn't been thought of. If
you do an internet search there are other imple
Interesting. Is this RFR a done deal?
While I like the concept and and understand the reasoning of URL not
having a public constructor, I think this may have been thought of in
isolation, I'm not sure how a custom URI, that strictly complies with
RFC 3986 will behave, if it must also be parse
Thanks Alan, comments inline below.
On 26/10/2022 11:07 pm, Alan Bateman wrote:
:
What would make a significant difference is returning non null
ProtectionDomain's for JDK modules, so we can reduce the size of the
trusted computing base, to make our job smaller, hopefully that will
allow
.jar", "read";
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission
"modifyPrivateCredentials";
permission javax.security.auth.AuthPermission
"modifyPublicCredentials";
};
Rega
27;t yet tested how our software will behave without the
PrivilegedAction's in JDK code, or preservation of AccessControlContext
in executor threads etc, but we need to start exploring that to fully
understand it before the SM removal JEP is created.
--
Regards,
Peter Firmstone
On 26
to utilise existing Permission check hooks after SecurityManager is
removed. Longer term we will need to maintain our own instrumentation
hooks, but this will go a long way towards giving us a head start, by
leveraging the existing.
--
Regards,
Peter Firmstone
Hi Sean,
I only just read this email, thanks, it allows us to start investigating
a new authorization layer.
Regards,
Peter.
On 21/04/2022 1:01 am, Sean Mullan wrote:
On 4/15/22 10:46 PM, Peter Firmstone wrote:
To securely instrument access controls onto public Java API, we need to
have
47 matches
Mail list logo
