, Peter Firmstone wrote:
Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a
configuration file with the SunPKCS11 Provider by default - We have
tests to register Providers while SecurityManager is in place. This
failed for SunPKCS11.
When you see
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 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
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
On 14/06/2021 6:37 pm, Alan Bateman wrote:
There are some libraries where the maintainers have put effort into
working with a SM.
Yes, I am one of them, very much so.
At first it's a shock, but the show must go on, it could be an
opportunity to address some long standing issues also.
If
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.
dvice on how this is intended to be handled by library
developers like me.
Best regards, Rafael
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
quot;java.security.policy" property doesn't
begin with "=" (which represents java.security.policy==).
Cheers,
Peter.
On 15/09/2019 10:58 PM, Alan Bateman wrote:
On 14/09/2019 21:21, Peter Firmstone wrote:
Hi Alan,
We've got a bunch of very old policy files in our test
"jrt:/jdk.crypto.ec" {
permission java.security.AllPermission "", "";
};
grant codebase "jrt:/jdk.crypto.mscapi" {
permission java.security.AllPermission "", "";
};
grant codebase "jrt:/jdk.localedata" {
permission
olicy provider as the
java.ext.dirs property is now blank, I also had to grant permissions to
a number of jdk modules, after fixing these, everthing running as
expected, except for a few minor test failures.
Next step will be to test against the EA builds.
On 17/08/2019 7:24 AM, Peter Firmstone
plementation on
coming EA builds would be greatly appreciated!
One thing we could do on the JDK end to reduce fragility somewhat in
this area is to provoke initialization of
sun.security.util.SecurityConstants before installing the first SM.
/Claes
On 2019-08-16 12:40, Peter Firmstone wrote:
Hello
alls.
Cheers,
Peter.
On 16/08/2019 5:04 PM, Alan Bateman wrote:
On 15/08/2019 23:20, Peter Firmstone wrote:
:
The following code is included in the constructor of our
SecurityManager implementation, I suspect we may need to add some
classes to this list, perhaps this is somethi
Hello Alan,
This is related to URL and CodeSource and might be worth making a note
of for future reference.
Our software uses delayed dynamically assigned permissions via a policy
provider, but for privileged domains that have AllPermission we make
sure to assign this up front (We also utili
Hello Claes,
The following code is included in the constructor of our SecurityManager
implementation, I suspect we may need to add some classes to this list,
perhaps this is something that needs documenting?
Regards,
Peter.
/* The following ensures the classes we need are loaded early to av
on of
the total number of objects,
depth, array sizes, and stream size. Since arrays are initialized with
data from the stream,
the stream size provides a practical limit.
Roger
On 8/29/16 10:07 PM, Peter Firmstone wrote:
>Include original message
>
> A quick thought on the arr
Include original message
A quick thought on the array size filter:
The system creates an array with a size read from the stream.
If Mallory sends a multidimensional array in the stream, then Mallory can
consume all jvm memory without exceeding the array size limit or the stream
data limit.
be up
to each class' class loader (and/or module) to determine what permission
is required in order to deserialize that class. In this way, the JDK
(9) can use a permission of the form class+module name for installed
module classes, Java EE systems could use permissions in the form of
applicati
If ObjectInputStream's creation was guarded by a Permission, this would
prevent serialization for untrusted users.
Regards,
Peter.
Original Message
Subject:Re: DeserializationPermission Proposal
Date: Fri, 12 Feb 2016 16:30:35 +1000
From: Peter Firmston
widen the scope,
which was contrary to the intended goal of minimising the attack
surface. In the end I decided to limit the context to only the domains
of classes involved in deserialization.
Cheers,
Peter.
On 02/11/2016 03:52 AM, Peter Firmstone wrote:
>/ An example might b
l not be able to construct this object unless all
domains have DeserializationPermission.
If we use the stack context, it won't contain the yet to be deserialized
classes.
Regards,
Peter.
On 11/02/2016 6:47 PM, Peter Firmstone wrote:
The use case here is:
Do we trust the code to d
would itself become unserializable.
Regards,
Peter.
On 02/08/2016 10:19 PM, Peter Firmstone wrote:
>/ Why not, just prior to instantiating an object just prior to deserializing,
add each class' ProtectionDomain in the objects hierarchy to an
AccessControlContext and pass
Thanks Chris,
Over the last year I've been working on reimplimenting OIS, I've been able to
retain serial form compatibility, but have made some changes to deserialization
api.
With the reimpl, existing Serializable objects that are stateless or those with
only primitive fields are allowed to
Why not, just prior to instantiating an object just prior to deserializing, add
each class' ProtectionDomain in the objects hierarchy to an
AccessControlContext and pass this to the SecurityManager's two argument
checkPermission call?
This permission could never be granted to a principal, it is
ee8 monitor is most likely being held by native code.
Regards,
Peter Firmstone.
Ok, but where? The deadlock report says it is held by main thread.
Somewhere between the following two java frames?
"main" #1 prio=5 os_prio=0 tid=0x017cf400 nid=0x1284 waiting for
m
y provider consume
around 10% cpu, this consumes less than 1%.
On 6/02/2016 9:57 PM, David Holmes wrote:
On 6/02/2016 9:39 PM, Peter Firmstone wrote:
Hmm, thought the new parallel lock stategy in ClassLoader wasn't
deadlock prone? Guess I was wrong.
The deadlock is introduced by a
Hmm, thought the new parallel lock stategy in ClassLoader wasn't
deadlock prone? Guess I was wrong.
Observation: On an unrelated occassion, I had a URLClassLoader
synchronization hotspot (well not standard URLClassLoader, but a high
performance RFC3986 URL ClassLoader, that use normalized RF
etely disabled or restricted to only those classes in use by an
application or reimplemented to allow input validation.
An OIS SPI would be a very simple straightforward solution.
Regards,
Peter Firmstone.
Sent from my Samsung device.
; data?
> >
> > Regards,
> >
> > Peter.
> >
> >
> > - Original message -
> > > I think you didn't understand the issue being discussed - it's not
> > > about fields that are added/removed, which is very clearly de
ppens when you don't call
> > defaultRead|WriteFields, which is required by spec but not always done
> > in practice.
> >
> > On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> > > The reason for this part of the spec, is backward compatible
> > > evolvab
is very clearly defined in the
> spec. It's about what happens when you don't call
> defaultRead|WriteFields, which is required by spec but not always done
> in practice.
>
> On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> > The reason for this part of the spe
The reason for this part of the spec, is backward compatible
evolvability of serial form.
It allows an earlier implementation of a class to deserialize serial
form from a later implementation that includes additional fields or
values written to the stream, and allow them to be discarded by
Ob
- Original message -
>From Peter Levart
Sent Fri, 20 Mar 2015, 01:21:17 EST
To Peter Firmstone , core-libs-dev@openjdk.java.net
Subject Re: RFR [9] 8071472: Add field access to support setting final fields
in readObject
> On 03/19/2015 11:35 AM, Peter Firmstone wrote:
>
Chris / Peter,
Perhaps you could consider passing GetFields as a parameter to a static
method (identified by an annotation) and use fieldSetter to change the
fields before they're written?
That way it would be possible to not only avoid implementing readObject
or writeObject, but to check in
Some performance figures, atomic de-serialization using loopback local
network sockets, codebase downloads, dynamic class loading, with
security manager and policies in force and Jini extensible remote method
invocation, there's communication going on between 4 different jvm
instances, the one
{
int keyHash = (key == null ? 0 : key.hashCode());
int valueHash = (value == null ? 0 : value.hashCode());
return keyHash ^ valueHash;
}
}
On 4/02/2015 1:13 AM, Peter Firmstone wrote:
Thanks Chris,
see below...
On 4/02/2015 12:14 AM, Chris Hegarty wrote:
Hi
Thanks Chris,
see below...
On 4/02/2015 12:14 AM, Chris Hegarty wrote:
Hi Peter,
On 2 Feb 2015, at 11:16, Peter Firmstone wrote:
As mentioned I've been experimenting with an invariant validating
ObjectInputStream, that's backward and forward compatible with Java's Object
ayed registration so that
* multiple live references in the object graph being
* deserialized can be registered in one batch.
*/
if (dgc) {
/*
* REMIND: short circuit lookup with thread local,
* to avoid synchronization overhead in
I decided to sample cpu load (see attached), with debugging enabled for
the validating ObjectInputStream and JERI, so heaps of output to the
console.
There are no performance optimisations with stream validation, I've just
focused on correctness and security.
Thank you HotSpot developers, ni
Two examples:
1. of a child class with super class invariants and
2. Checking List and Map contents for type correctness.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional
lse);
}
}
throw new InvalidObjectException(
"AvailabilityEvent should always have data");
}
On 29/01/2015 8:10 PM, Peter Firmstone wrote:
Another example of intra dependencies, turns out we have a lot of
these intra class dependencies in our project.
Cheers,
Peter.
/*
* Li
Another example of intra dependencies, turns out we have a lot of these
intra class dependencies in our project.
Cheers,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for a
Logging output from failed validation:
NonActGrp-out: Jan 29, 2015 7:36:16 PM
net.jini.jeri.BasicInvocationHandler invoke
NonActGrp-out: Jan 29, 2015 7:36:16 PM
net.jini.jeri.BasicInvocationHandler invoke
NonActGrp-out: FAILED: outbound call
net.jini.core.event.RemoteEventListener.notify remot
vider, after being
obtained from a lookup service, this was premised on java's secure
sandbox and serialization, when it was believed to be secure.
Regards,
Peter.
On 29/01/2015 7:08 PM, Peter Firmstone wrote:
Although not directly relevant to this discussion, here are some
functional e
Although not directly relevant to this discussion, here are some
functional examples of deserialization constructors, I now have a fully
functional validating ObjectInputStream.
Unfortunately in our project we have intra object dependencies as
demonstrated by this example; a static validator,
. Lloyd"
>
> At some point, the responsibility *must* fall on the author of the
> serializable class in question to avoid constructs which are exploitable
> - like finalizers, and classes that can have side-effects before
> validation can be completed.
>
> On 01/21/2
-Chris.
While deserializing, the object is in inconsistent state. If
deserialization fails, this state is rolled-back to uninitialized state.
finalize() can still get to the instance, but it will be uninitialized.
Peter
On 01/14/2015 01:58 PM, Peter Firmstone wrote:
Hi Chris,
Sorry, no.
Cur
- Original message -
> On 15/01/15 20:33, Peter Firmstone wrote:
> > Thanks Chris,
> >
> > WRT circular references, is it possible to detect and delay setting
> > these until after all verifiers run?
>
> It is possible to detect the circular reference.
g a constructor in future?
Regards,
Peter.
- Original message -
> On 15 Jan 2015, at 12:25, Peter Firmstone
> wrote:
>
> > Chris,
> >
> > Can you explain some of the detail in your failure atomicity work?
>
> Certainly.
>
> The current implement
On 13/01/2015 1:56 AM, Chris Hegarty wrote:
On 10/01/15 07:00, Peter Firmstone wrote:
As shown in my earlier example, intra class invariants can be enforced
using Serialization constructors, from which static methods are called
to check invariants prior to super class constructors being called
Chris,
Can you explain some of the detail in your failure atomicity work?
Thanks,
Peter.
The following is a summary of our exploration so far:
We have narrowed down to two options:
A. constructors with static invariant check methods.
B. Continue to use readObject(), we have a proposed solution to the
final field problem and could modify the jvm to register for
finalization lat
cing invariants after calling a
superclass constructor, is far more complicated.
Using a serial constructor, is less evil.
Regards,
Peter.
- Original message -
> On 14/01/15 12:58, Peter Firmstone wrote:
> > Hi Chris,
> >
> > Sorry, no.
> >
> > Current
enario is along the same lines as yours, then I just don't see
> how 1c above will always be possible.
>
> If we could somehow make the object caller sensitive until after
> deserialization completes, then could avoid having to try to allocate
> multiple instance down the hie
Could we use a static validator method and generate bytecode for constructors
dynamically?
The developer can optionally implement the constructors.
static GetField invariantCheck(GetField f);
Create a caller sensitive GetField implementation and add a two new methods to
GetField:
abstract Obj
- Original message -
> On 10/01/15 07:00, Peter Firmstone wrote:
> > Again, thank you all for engaging in discussion of this very difficult
> > topic.
> >
> > While we can't presently check intra object dependencies during
> > deserialization wit
Again, thank you all for engaging in discussion of this very difficult
topic.
While we can't presently check intra object dependencies during
deserialization with readObject(), the examples I provide can do this.
ObjectInputValidation is sufficient for enforcing business rules,
however it ca
Thank you all for participating in this discussion.
Initially a constructor signature for deserialization was proposed to
enforce invariants and encapsulation, however there appears to be
interest in using alternative methods, although they appear to be
improvements over the status quo, I'm ha
- Original message -
> > > On 5/01/2015 6:51 PM, Peter Firmstone wrote:
> > > > Thanks Dave,
> > > >
> > > > That's another way of checking invariants, you could expose A's
> > > > check method but you'd also need a
My mistake, thank you.
Peter.
On 5/01/2015 9:57 PM, David Holmes wrote:
Hi Peter,
Did you send this to the list? I haven't seen it turn up yet.
David
On 5/01/2015 6:51 PM, Peter Firmstone wrote:
Thanks Dave,
That's another way of checking invariants, you could expose A's c
- Original message -
>
> On 01/04/2015 02:48 AM, Peter Firmstone wrote:
> > class B extends A {
> >
> > public final int cur;
> >
> > private static ReadSerial check(ReadSerial rs) {
> > A a = new A(rs);
>
> What to do if A is abstract
On 4/01/2015 9:55 AM, Peter Levart wrote:
- Original message -
>
> As Brian points out, this scheme can only validate intra-class
> invariants. It can't validate class-against-subclass state.
Sorry, I meant it can't validate class -against-superclass state.
Did he say that?
Not dir
e my reference if I find invarients aren't satisfied?
Peter.
- Original message -
> Just a quick comment about the finalization aspect ( as I have been
> thinking about this too ).
>
> On 3 Jan 2015, at 15:36, Peter Levart wrote:
> > On 01/03/2015 01:38 PM, Pe
- Original message -
>
> As Brian points out, this scheme can only validate intra-class
> invariants. It can't validate class-against-subclass state.
Did he say that?
It's true that a superclass can't validate subclass state, it can't be expected
to know much about it, but it can validat
to fields of objects in the form of annotations or
> such (see what JPA is doing in this field). Combined with
> post-deserialization invariant-checking call-back method perhaps.
>
> Regards, Peter
>
> >
> > Obviously you have to patch one or the other instan
should make it final, provide and call a protected method for subclasses to
implement, should they too contain circular links.
The alternative is to use a private method, but it's a lot more convenient to
use an interface.
Unfortunately the only remaining option to protect invarients is to make
> constructors:
>
> class SubFoo extends BaseFoo {
> private final int y;
>
> public SubFoo(ReadSerial rs) {
> this(rs.getInt("y"));
> }
>
> public BaseFoo(ReadSerial rs, int y) {
>
y"));
> }
>
> public BaseFoo(ReadSerial rs, int y) {
> super(rs);
> this.y = y;
> }
> }
>
> Is this what you envision?
>
>
>
>
>
> On 12/27/2014 8:03 PM, Peter Firmstone
final static fields, but don't allow
static initializer blocks or mutable static fields, similar to
interfaces.
Penny for your thoughts?
Regards,
Peter Firmstone.
.
I'll keep an eye out for the JSR.
When is a better timeframe, roughly, to discuss Serializable?
Regards,
Peter.
- Original message -
> On 11/08/2014 13:06, Peter Firmstone wrote:
> > Thanks Alan, I can relate to time poverty :)
> >
> > I might be assuming t
eugster/Ribbons/RJ.pdf
https://www.cs.purdue.edu/homes/peugster/Ribbons/
Got any links to info on extending access control rules?
Regards,
Peter.
On 11/08/2014 9:21 PM, Alan Bateman wrote:
On 09/08/2014 06:56, Peter Firmstone wrote:
I've noticed there's not much interest in improving Seri
On 11/08/2014 8:12 PM, Peter Firmstone wrote:
Brian,
Thanks for picking up on my frustration ;)
I have something in mind for Serializable2 to address cyclic data
structures and the possibility of independant evolution of super and
child classes, while retaining a relatively clean public api
Brian,
Thanks for picking up on my frustration ;)
I have something in mind for Serializable2 to address cyclic data
structures and the possibility of independant evolution of super and
child classes, while retaining a relatively clean public api, with one
optional private method. The methods
I've noticed there's not much interest in improving Serialization on these
lists. This makes me wonder if java Serialization has lost relevance in recent
years with the rise of protocol buffers apache thrift and other means of data
transfer over byte streams.
The burden of implementing Seriali
On 28/07/2014 7:28 PM, Peter Firmstone wrote:
Updated files attached, including update to State of Serialization draft.
For those who didn't get the attachment:
*State of Java Serialization - Draft*
Introduction
The Java Serialization framework enables object state to be frozen,
s
Updated files attached, including update to State of Serialization draft.
Note that the attached source code can be provided under the Oracle
agreement.
I'm a little time poor, so please contribute suggestions etc.
Regards,
Peter.
On 26/07/2014 7:57 PM, Peter Firmstone wrote:
I'
witch
On 22/07/2014 1:10 AM, Tom Hawtin wrote:
On 20/07/2014 11:57, Peter Firmstone wrote:
Since private methods are only be called by the ObjectOutputStream /
ObjectInputStream, during de-serialisation, subclass are not responsible
for calling these methods, hence subclass ProtectionDomain
David,
I've gone over the list archives and read your earlier post about
serializable constructors and agree with your post.
The class SerialFields below, represents the serial form of a
Serializable object, the stream protocol would remain unchanged.
SerialFields would be the equivalent of
Who said security and RMI had to be performance dogs?
Anyone ever notice it's native code that uses all the CPU?
100% CPU Utilisation
0% monitor
Peak live threads 99
Test run time 2 minutes.
4891 Remote Object Invocations, includes remote code downloading and
class loading (thread confined).
k java.rmi.MarshalledObject}
* is un-marshaled, a {@link java.rmi.MarshalledObject} must first be
* converted to {@link net.jini.io.MarshalledInstance} before un-marshaling.
*
* @author Peter Firmstone.
* @since 3.0.0
*/
public interface Portable {
/**
* Prepare for transport in
80 matches
Mail list logo
