Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

Hi Sean,

Regarding the section entitled "Why not write a new serialization 
library?", unlike the serialization libraries listed, our purpose was to 
be able to securely deserialize untrusted data, while maintaining 
backward serial form compatibility with Java Serialization, provided it 
didn't compromise security.

We don't use blacklists or whitelists, we use permissions to grant 
DeserializationPermission, it doesn't have the granularity of white 
lists, but then, classes that implement @AtomicSerial are supposed to be 
hardened implementations in any case.

If it can be of use, feel free to experiment with it, hopefully it might 
help with some of your design decisions:

https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io

Much of the code on this site provides implementation examples as well.

Regards,

Peter.

On 20/08/2019 7:55 AM, Sean Mullan wrote:
> Brian Goetz (copied) has done a lot of thinking in the serialization 
> area, so I have copied him. Not sure if you have seen it but he 
> recently posted a document about some of his ideas and possible future 
> directions for serialization: 
> http://cr.openjdk.java.net/~briangoetz/amber/serialization.html
>
> --Sean
>
> On 8/17/19 10:22 PM, Peter Firmstone wrote:
>> Thanks Sean,
>>
>> You've gone to some trouble to answer my question, which demonstrates 
>> you have considered it.
>>
>> I donate some time to help maintain Apache River, derived from Sun's 
>> Jini.  Once Jini depended on RMI, today, not so much, it still has 
>> some dependencies on some RMI interfaces, but doesn't utilise JRMP 
>> although it provides some backward compatibilty enable it.
>>
>> But my point is, we heavily utilise java Serialization, and have an 
>> independant implementation of a subset of Java Serialization 
>> (originating from Apache Harmony).  We do this for security as we use 
>> an annotated serialization constructor.   Serial form is unchanged, 
>> we have Serializers for commonly used java library objects, for 
>> example, we have a "PermissionSerializer", but we don't have a 
>> "PermissionCollectionSerializer" or "PermissionsSerializer" (for 
>> java.security.Permissions).   Incidentally, we have found we do not 
>> need the ability to serialize circular object graphs.   Throwable is 
>> an object that has a circular object graph, but that circular object 
>> graph can be linked up after deserialization.
>>
>> Permission implementing Serializable is probably not too much of a 
>> threat, as these objects are effectively immutable after lazy 
>> initialization.
>>
>> ProtectionDomain calls java.security.Permissions::setReadOnly during 
>> it's construction.
>>
>> ProtectionDomain::getPermissions returns internal 
>> java.security.Permissions.   If this is serialized, then the readOnly 
>> internal state can be written to as the internal object references 
>> are accessible from within the stream.
>>
>> Admitedly, the attacker would already need to have some privilege, to 
>> have access to a ProtectionDomain, so it's a path of privilege 
>> escallation.  I'm not talking about gadget attacks and 
>> deserialization of untrusted data, I'm talking about breaking 
>> encapsulation.
>>
>> Even though we are heavily dependant on Java Serialization, we are 
>> very careful when we implement it, and avoid implementing it when 
>> possible. Hindsight is 20:20, but given we are now seeing some Java 
>> SE backward compatibility breakages, perhaps it might be worth 
>> considering breaking serialization.  I don't mean we need to 
>> necessarily break object serial form, but making the Java 
>> serialization API explicit with subset of existing api features, that 
>> makes long term maintenace and security less of a burden and removing 
>> support for Serialization of some objects, where it is seldom used, 
>> perhaps using a JEP that requests developers to consider which 
>> library objects actually need to be serializable.
>>
>> Something we do in our Java Serialization API is require that mutable 
>> deserialized objects are defensively copied during object 
>> construction (serial fields are deserialized before an object is 
>> constructed, the deserialized fields are accessible via a parameter 
>> passed in during construction.   We have tools that assist developers 
>> to check deserialized Java Collections contain the expected object 
>> types for example, so during object construction the developer has to 
>> replace the Collection with a new instance and copy the contents to 
>> the new Collection after checking the type of each object contained 
>> therein. Also we don't actually serialize Java Collections, we have 
>> standard serial forms for List, Set and Map, so these serial forms 
>> are equal, similar to the List, Set and Map contracts.  By doing 
>> this, Collections don't actually need to implement Serializable at 
>> all, as a Serializer becomes responsible for their serialization.   
>> This also means that all Collections must be accessed by interfaces, 
>> rather than implementation classes, so the deserialization 
>> constructor, must defensively copy them into their preferred 
>> Collection instance.   It's a bit like dependency injection.
>>
>> I know it would take time, and there would be some pain, but long 
>> term it would save a lot of maintenance developer time.
>>
>> Regards,
>>
>> Peter.
>>
>> On 17/08/2019 12:50 AM, Sean Mullan wrote:
>>> On 8/15/19 8:18 PM, Peter Firmstone wrote:
>>>> Hi Roger,
>>>>
>>>> +1 for writeReplace
>>>>
>>>> Personally I'd like to see some security classes break backward 
>>>> compatibility and remove support for serialization as it allows 
>>>> someone to get references to internal objects, especially since 
>>>> these classes are cached by the JVM.  Which makes 
>>>> PermissionCollection.setReadOnly() very easy to bypass, by adding 
>>>> permissions to internal collections once you have a reference to them.
>>>>
>>>> Does anyone have any use cases for serializing these objects?
>>>>
>>>> These objects are easy to re-create by sending or recieving and 
>>>> parsing strings, because they are built from text based policy 
>>>> files, and when you do that, you are validating input, so I never 
>>>> did fully understand why they were made serializable.
>>>
>>> This is briefly explained on page 61 in the "Inside Java 2 Platform 
>>> Security" book [1]:
>>>
>>> "The Permission class implements two interfaces: java.security.Guard 
>>> and java.io.Serializable. For the latter, the intention is that 
>>> Permission objects may be transported to remote machines, such as 
>>> via Remote Method Invocation (RMI), and thus a Serializable 
>>> representation is useful."
>>>
>>> The Permission class was introduced in Java SE 1.2 so there were 
>>> different motivations back then :)
>>>
>>> --Sean
>>>
>>> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html
>>