may put us at a significant disadvantage.
Regards,
Peter.
On 2/05/2022 5:24 pm, arjan tijms wrote:
Hi,
On Monday, May 2, 2022, Peter Firmstone
wrote:
I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as
edesign it,
unentangling our dependency on SM isn't a simple problem to solve.
I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as it is
in deprecated form for a number of years, that would be greatly appreciate
attacker would probably be unable to penetrate the jvm,
but still could potentially steal data.
On 28/04/2022 3:25 pm, Peter Firmstone wrote:
Hi Martin,
Your arguments are the reasons why we use the principle of least
privilege. It creates a headache for attackers, similar to the
developer
had access controls for 24 years, we couldn't foresee that it
would be removed in a breaking manner in such a short time frame.
Remember how long Thread.stop and similar bad api's remained in
deprecated form?
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204243
This isn&#
defenses against
parsing untrusted data, all these things happen to be bolted on
afterthoughts.
Regards,
Peter.
On 26/04/2022 11:07 pm, David Lloyd wrote:
On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote:
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or deleg
On 26/04/2022 8:10 pm, Alan Bateman wrote:
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run
mstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java
-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-8155659
It's just such a shame that we achieved so much and OpenJDK is pulling
the rug from underneath us.
Regards,
Peter.
pport this JDK version.
Personally I'd like to see SM fully supported until finalizers can be disabled.
--
Regards,
Peter Firmstone
layer, hopefully we'll learn from Java's mistakes, not
repeat them, but make a bunch of new mistakes instead.
Regards,
Peter.
On 23/04/2022 12:58 pm, Martin Balao wrote:
Hi,
On 4/8/22 11:13 AM, Sean Mullan wrote:
In general, I think authorization is best done at a higher layer within
/8349
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
ms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L853
Would be nice to do some testing with the changes.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
On 18/04/2022 2:24 am, liach wrote:
Convert dynamic proxies to hidden classes. Modifi
flag be provided to
disable jvm calls to finalizer methods.
--
Regards,
Peter Firmstone.
Thanks for trying David. :)
Regards,
Peter.
On 8/04/2022 7:15 pm, Andrew Dinn wrote:
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team
with just as much -- or possibly more -- code to maintain, test and
design around while making the behaviour under the retained API
hecks and calls to
SecurityManager, OpenJDK devs just need to ensure they are using these
standard control points / hooks.
Regards,
Peter.
On 8/04/2022 5:19 am, Sean Mullan wrote:
Hi David,
Thanks for the feedback and spending some time on this proposal. Some
specific comments below.
On 4
Looks good to me, removes credentials when phantom reachable, doesn't do
anything that would prevent it from becoming reachable. You removed the
GNSSException that wasn't thrown.
Regards,
Peter.
On 7/04/2022 2:17 pm, Xue-Lei Andrew Fan wrote:
Please review the update to remove
, but authentication goes a long way to filtering out potential
attack vectors.
--
Regards,
Peter
On 5/04/2022 11:52 pm, David Lloyd wrote:
Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact
susceptible to some form of injection
attack, as it has to parse untrusted data.
Be sure to disable Serialization, as SM doesn't prevent its use and any
other forms of potentially dangerous data parsing.
-Djdk.serialFilter=!*,\
-Dcom.sun.jndi.ldap.object.trustSerialData=false,\
Regards,
iming,
locking or gc:
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-security-debug-fine-logging-tls-handshake.txt
Regards,
Peter.
On 12/08/2021 5:32 am, Jamil Nimeh wrote:
Hi Peter,
I've captured the issue in
https://bugs.openjdk.java.net/browse/JDK-8272340. Th
WARNING that the socket didn't close, followed by an ERROR, then
FATAL(UNEXPECTED MESSAGE).
致以诚挚的问候Peter.
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt
[java] ActSys-err: javax.net.ssl|DEBUG|92
x27;s
pitfalls.
Watch this space, I'll post a link when ready.
Regards,
Peter.
On 5/08/2021 7:27 am, Sean Mullan wrote:
On 8/3/21 8:10 PM, Peter Firmstone wrote:
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the f
Maybe we need some criteria, that defines what's not easily instrumented?
On 4/08/2021 10:19 am, Peter Firmstone wrote:
Excellent, Ron, that's exactly what I'm after.
I need to be able to implement an authorization layer on top of the
JDK, but reach down into the JDK to use a
* User Credentials
Maybe we should have a mailing list dedicated to this where we can
discuss and potentially collaborate?
Regards,
Peter.
On 3/08/2021 10:15 pm, Ron Pressler wrote:
On 3 Aug 2021, at 12:50, Peter Firmstone wrote:
Can you think of any workable alternative comprom
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. TLS and Kerberos connections cannot be established. (My
software is
littered with doPrivileged calls that
does nothing by default
and would be optimised away by hotspot.
eg:
static instrumentGuard(String [] args) throws SecurityException{}
Thanks,
Peter.
The starting point isn’t removing the policy file implementation, but removing
all access checks
and privileged operations from the JDK, and
Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for
line numbers in code
Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone wrote:
We can still use these without an SM, Policy or Permissions for authorization
decisions, as mentioned previously I'd replace the inherited thread context
wi
On 3/08/2021 6:31 pm, Ron Pressler wrote:
On 3 Aug 2021, at 02:30, Peter Firmstone wrote:
I am still hopeful that OpenJDK might create some hooks for us and keep the
AccessController, AccessControlContext and Subject.doAs methods to make
supporting all Java versions easier.
When I
ain's on the stack. We don't need to call
ProtectionDomain::Implies(Permission) to make authorization decisions.
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java
--
Regards,
Peter
On 3/08/2021 11
hings, such as deserialization (not to be
confused with Java Serialization) and network connections. The dynamic
grants are removed by garbage collection. Dynamic grants are probably
very rare for most developers, although OSGi also supports dynamic
grants also, I had a discussion with Peter K
more
than I've posted, I suggest you do the same and direct your attack onto
problems, rather than people.
Thank you.
Peter.
On 2/08/2021 11:07 pm, Andrew Dinn wrote:
On 02/08/2021 11:33, Peter Firmstone wrote:
I think you may be misinterpreting my comment, let me clarify:
Really? I'
we suggested,
I'd support that. I'm also grateful that Uwe spoke up, and I hope
others do as well, so this topic receives further productive
discussion. It would be nice to sort the use cases prior to SM
removal. JEP 411 appears symbolic at this stage anyway, more JEP's
will
ops global service
discovery over IPv6, and constrains the software in many other areas as
well, so it's not being considered at this time.
Regards,
Peter.
On 2/08/2021 4:23 pm, Florian Weimer wrote:
* Peter Firmstone:
From our discussions, my interpretation is that OpenJDK is const
he more people who speak up about their
use of SM, as an authorization layer, rather than a sandbox for code
with malicious intent, the less OpenJDK will consider this use of SM is
a /special case/.
Regards,
Peter.
e affected JVM is immediately restarted.
Our code is dynamic, so we might need to create an audit service that
provides a list of audited proxy codebases and their SHA-256 hashes.
Keep in mind this is all completely experimental and subject to change.
Regards,
Peter.
On 31/07/2021 6:22 pm, Ro
remove finalizers soon, prior to removal of SM.
Regards,
Peter.
On 31/07/2021 5:35 pm, Alan Bateman wrote:
On 31/07/2021 04:04, Peter Firmstone wrote:
Allan has advised when finalizers are removed, it will be practical
to use Agents to instrument public API to implement an authorization
la
sential for the survival of Java, Java has already shed
phone and client markets, lets not shed too many more.
Thanks,
Peter
Appended inline below.
On 29/07/2021 11:20 am, Peter Firmstone wrote:
The intent of the following process is to perform a targeted audit,
which allows inspection of small parts of the code identified by these
steps.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process for
The intent of the following process is to perform a targeted audit,
which allows inspection of small parts of the code identified by these
steps.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process for establishing whether third party libraries are trusted
before we use them:
1
mpiled, perhaps a subset of Haskell
parsed as source code, if I used it for that, then it's audited by
parsing and the compiler. I guess something similar could be done with
ASM and bytecode, but it's not my goal to run untrusted code, I'll leave
the sandbox for the develope
On 28/07/2021 9:12 am, Peter Firmstone wrote:
While its possible to use a dynamic proxy without downloading code,
via an atomic serialization connection, it's not generally advised to
do so with unauthenticated users, decisions around dynamic discovery,
whether class loading or download
(very well supported, Oracle should sell these lol,
the only drawback is no zfs) is a good idea, no Spectre or Meltdown
vulnerabilities.
buffy$ uname -a
OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64
Although this one's a couple of versions behind, time for an upgrade.
Regards,
Peter.
O
brought it
forward. If Haskell is a magnitude more efficient, as its proponents
claim, then it may ultimately provide an overall cost saving. We
haven't made a choice yet though, it's still under investigation.
I do appreciate that you took the time to respond to my emails.
Reg
ng, data parsing, etc.
Rather than a sandbox, it just needs to be safer, with the ability to
allow access to the underlying Java / C / etc, to trusted /
authenticated / verified entities.
If anyone has any ideas regarding suitable languages, I'd be very
interested to hear your thoughts.
--
Regards,
Peter Firmstone
e to secure the underlying
platform, or at least use it securely. Arguably we can do things now
that aren't possible on other platforms, so we need to develop that
capability as well, not just secure it.
Regards,
Peter.
On 23/07/2021 9:45 pm, Alan Bateman wrote:
On 23/07/2021 11:48,
t
great performance, all our hotspots were native methods and Java let us
get close to the metal at low levels as well using bit shift operations
on primitives, that are magnitudes faster than standard string
operations. TLS ran so much faster with stateless session tickets too.
Regards,
original JVM with classes from the fork?
I sure wish there was a better option, if anyone knows one, I'm all ears.
Regards,
Peter.
On 23/07/2021 6:36 pm, Peter Firmstone wrote:
Post JEP 411, we need to write Agents to replace the current
permission checks performed within the J
s for our TLS
and Kerberos connections, for authentication, I've created support for
obtaining the Subject from the Authorization context, in my
authorization layer software (linked above), but instrumenting private
methods in the JDK goes against all previously learned best practices.
--
Reg
y personal thoughts and opinions, I do realize
that they are probably unwelcome here.
Regards,
Peter.
On 22/07/2021 5:31 am, Sean Mullan wrote:
Hi,
I am not an expert in JSR 223. However, some JSR 223 implementations
include a mechanism for restricting access to Java classes, for
example Nas
Thanks Sean,
Be nice if it can be implemented in a way that allows it to be decorated.
Regards,
Peter.
On 19/07/2021 10:29 pm, Sean Mullan wrote:
On 7/17/21 9:13 PM, Peter Firmstone wrote:
My mistake copied wrong bug:
Has there been any progress with the new Subject API?
https
ore documentation:
https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java
Note this authorization layer also provides a way to preserve a user
Subject across threads for authentication of TLS and Kerberos connections.
Peter.
On
My mistake copied wrong bug:
Has there been any progress with the new Subject API?
https://bugs.openjdk.java.net/browse/JDK-8267108
On 17/07/2021 2:53 pm, Peter Firmstone wrote:
Thanks Sean,
Has there been any progress with JDK-8264713?
https://bugs.openjdk.java.net/browse/JDK-8264713
rotectionDomain());
} finally {
INHERITED_CONTEXT.set(authorization);
}
}
On 16/07/2021 2:20 pm, Peter Firmstone wrote:
I'm currently experimenting with a new authorization layer for java,
post JEP 411.
I would like your thoughts around threads.
This is intende
Thanks Sean,
Has there been any progress with JDK-8264713?
https://bugs.openjdk.java.net/browse/JDK-8264713
Regards,
Peter.
On 16/07/2021 11:44 pm, Sean Mullan wrote:
JEP 411 has been updated with a few changes:
1. The "Description" section [1] has been updated with more detai
, may be thought of as a
system domain, should it create threads, then provided those threads
only have privileged domains on the stack, guard checks may proceed.
For unprivileged application code, all guard checks fail.
Any thoughts or questions?
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
Updated authorization layer prototype:
https://github.com/pfirmstone/HighPerformanceSecurity
On 30/06/2021 9:38 pm, Peter Firmstone wrote:
A draft Authorization implementation, untested.
--
Regards,
Peter Firmstone
A draft Authorization implementation, untested.
--
Regards,
Peter Firmstone
/**
* Authorization class, instances contain the domains and Subject of the
* Authorization context, used for Authorization decisions by Guard
* implementations. Provides static utility methods to make
27;s principals.
6. GuardFactory and GuardFactorySpi, Authorization agents will need to
call GuardFactory, to obtain Guard instances, the Guard
implementation can call:
* Authorization::getContext()checkEach(domain -> doSomething(domain));
--
Regards,
Peter Firmstone
On 26/06/20
On 26/06/2021 3:41 pm, Peter Firmstone wrote:
Apologies for multiple earlier emails, please ignore and read this
instead.
This proposal is about stripping out and simplifying as much of the
dilapidated and complex SecurityManager infrastructure as possible,
while retaining the ability for
y of implementation.
Regards,
Peter Firmstone.
On 25/06/2021 3:59 pm, Peter Firmstone wrote:
Thanks Dalibor,
Would targeting Java 18 be practical?
Also it won't take long to code a prototype, just not sure of the
process.
Cheers,
Peter.
On 24/06/2021 9:30 pm, Dalibor Topic wrote:
On
Inline.
On 26/06/2021 1:46 pm, Peter Firmstone wrote:
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks
On 26/06/2021 1:48 pm, Peter Firmstone wrote:
The innocuous AccessControlContext, is intended to have no permission,
hence it is constructed using the two argument ProtectionDomain
constructor, which causes ProtectionDomain to not consult the Policy.
However, if a user obtains this
innocuous AccessControlContext instead be given a
ProtectionDomain, with a non-null CodeSource, which has a null URL. This
is also considered by the Policy to be unprivileged.
--
Regards,
Peter Firmstone
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead retu
mbiner.
This is backward compatible with existing usages of JAAS and least
painful method of transition for all concerned as well as allowing
complete flexibility of implementation.
Regards,
Peter Firmstone.
On 25/06/2021 3:59 pm, Peter Firmstone wrote:
Thanks Dalibor,
Would target
er.doPrivileged, or Thread context, which limits viral
authorization checks).
3. ProtectionDomain, CodeSource and Principal
4. JAAS, Subject and LoginModule.
5. GSS-API/Kerberos, JCA, JCE and JSSE.
--
Regards,
Peter Firmstone
On 24/06/2021 11:50 am, Peter Firmstone wrote:
Clarification
Thanks Remi,
We're still building on 8, for CORBA-IIOP stubs, but will look into this
when we've found an alternative IIOP stub compiler.
--
Regards,
Peter
On 23/06/2021 8:02 pm, Remi Forax wrote:
- Mail original -
De: "Andrew Dinn"
À: "Peter Fi
Java, provided we
have some basic things like JVM hooks for access checks.
--
Regards,
Peter Firmstone
On 23/06/2021 7:19 pm, Andrew Dinn wrote:
OHi Peter,
n 23/06/2021 04:02, Peter Firmstone wrote:
1. StackWalker - Can stack walker be back ported to Java 8?
The right place to ask about this i
Clarification inline below.
On 24/06/2021 11:03 am, Peter Firmstone wrote:
Hi Alan,
It is important to understand the reason for the inherited
AccessControlContext, in order to consider alternatives.
The motivation for inherited context, was simply to avoid privilege
escalation, prior to
reads
that do not support any permissions at all.
--
Regards,
Peter Firmstone
On 23/06/2021 4:34 pm, Alan Bateman wrote:
On 23/06/2021 04:02, Peter Firmstone wrote:
Note: I'm not sure how to replace an inherited AccessControlContext
(with a new implementation based on StackWalker func
Thanks Seán,
A good explanation. :)
Solaris was a very good platform for exposing and debugging race
conditions, of course we have very good static analysis now.
Regards,
Peter.
On 23/06/2021 5:10 pm, Seán Coffey wrote:
Thank for the feedback Peter. Comments inline.
On 22/06/2021 22:40
"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. The use case for this is for
servers to grant it to authenticated users (user supplied input data),
so that it can only be performed following user authentication.
Existing Permission implementations
--
Regards,
Peter Firmstone
sion
"accessClassInPackage.sun.security.util.math";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util.math.intpoly";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.x509";
};
Good call making NativeReso
expand the SocketPermission to the local subnet, and
it would shrink the size of the generated policy file by eliminating
other SocketPermission grants to IP addresses on the subnet.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
On 18/06/2021 1:18 pm, Peter Firmstone wrote:
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly compl
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly complex in mind, could you give
some practical exampl
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
Regards,
Peter.
alk.
We also have existing classes which wrap AccessControlContext, so we
would use ThreadLocal's to preserve subject.
--
Regards,
Peter.
On 16/06/2021 1:56 am, Alan Bateman wrote:
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One b
will come to be as performant as our current
implementation.
Regards, Peter.
For my part, supporting the security manager seems to be the right
choice as things stand today.
Over the years, I would expect that fewer and fewer people rely on the
security manager, where this balance might shift. I wou
On 15/06/2021 2:23 am, David Lloyd wrote:
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing
personally I wouldn't remove these
classes, but it's not my choice.
--
Regards,
Peter.
VM's with unmaintained OS's.
Peter.
On 14/06/2021 6:37 pm, Alan Bateman wrote:
On 14/06/2021 08:35, Peter Firmstone wrote:
I wouldn't want to see SecurityManager and Policy be neutralized,
it's better to remove it and fail early so people update their
software, there
MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. Granted to users, so that it can
only be performed after authentication.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
t
need permission implementations to remain compatible.
Whatever happens with JAAS will need to be backported, so we can support
all versions.
Regards,
Peter.
On 14/06/2021 3:54 pm, Alan Bateman wrote:
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the firs
Forgot to cc.
Forwarded Message
Subject: Re: Low level hooks in JDK for instrumentation of permission
checks.
Date: Mon, 14 Jun 2021 15:13:15 +1000
From: Peter Firmstone
To: jdk-...@openjdk.java.net
Clarification, utilize java.security.Provider.
So this might
"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code ab
s the ability to customize Permission
implementations, such as allowing address ranges in a SocketPermission
implementation and not consulting DNS to resolve host names.
Cheers,
Peter.
On 10/06/2021 11:55 pm, Alan Bateman wrote:
On 10/06/2021 07:40, Peter Firmstone wrote:
Just a quick que
ed confirm
Permission checks are made and functionality of the AccessController and
AccessControlContext methods if these are retained (I would prefer to
see that, at least for JAAS compatibility).
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
Regards,
Peter.
On 9/06/2021 11:35 am, Peter Firmstone wrote:
Apologies in advance if this seems like paranoid security.
As you are likely now aware, we have been using
ty to make ProtectionDomain a little more
useful if it maps to modules.
Gut feel is it would be relatively low risk, but as you correctly state,
would require testing.
I'm not able to lodge on Jira, but I thought this would be worthy update.
Regards,
Peter.
On 10/06/2021 4:22 pm, Alan Bateman w
ad of null?
A CodeSource with URL's like jrt:/jdk.* or jrt:/java.* for system modules?
Hopefully my comments below will make a little more sense now.
Regards,
Peter.
On 10/06/2021 1:07 am, Sean Mullan wrote:
On 6/8/21 9:35 PM, Peter Firmstone wrote:
I would also like to request that all
ed to add synchronization to use it.
-
PR: https://git.openjdk.java.net/jdk/pull/4400
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
.locale.provider";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.resources";
};
grant codebase "jrt:/jdk.security.auth"
{
permission java.io.FilePermission
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniha
Don't bother replying.
I found that it is actually on the TODO list.
https://bugs.openjdk.java.net/browse/JDK-8266592
I've had enough now anyway, there is no fixing this mess.
Sayonara.
On 4/06/2021 2:22 pm, Peter Firmstone wrote:
Could someone please advise the recommended
that that isn't the case, I just want
some guidance, I think our whole code base and how we use Java, just bit
the dust.
--
Regards,
Peter.
Sean,
Also moving forward we currently preserve AccessControlContext across
threads, and we do this to establish TLS connections for call backs.
Will there be a new way to preserve the calling Subject across threads,
so we can perform callbacks over TLS?
Regards,
--
Regards,
Peter
ing about
removing, then we need to know, so we don't use them in our new
authorization layer.
--
Regards,
Peter Firmstone
On 4/06/2021 1:02 am, Sean Mullan wrote:
On 6/2/21 7:41 PM, Peter Firmstone wrote:
AccessController and AccessControlContext allow backward compatiblity
for JAAS
se case, then yes I would
encourage you to upgrade, because that's the sensible thing to do.
I'll still test on later versions, but I won't be removing our
authorization system until I'm satisfied there are sufficiently hardened
alternative technologies available.
Thank you
https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/
Cheers,
Peter.
On 3/06/2021 7:33 pm, Ron Pressler wrote:
On 3 Jun 2021, at 00:41, Peter Firmstone wrote:
StackWalker doesn't work with compiled code, only bytecode.
If you’re referring to GraalVM’s Native Image, I
some consideration.
--
Regards,
Peter.
On 3/06/2021 5:18 pm, Alan Bateman wrote:
On 03/06/2021 01:04, Chapman Flack wrote:
On 06/02/21 19:41, Peter Firmstone wrote:
We need the power of AccessController's stack walk, StackWalker
doesn't work
with compiled code, only bytecode.
Is
1 - 100 of 256 matches
Mail list logo
