[12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

[Roger Riggs]

Hi,

In the case of supplying a filter to getObject the caller is 
intentionally replacing
the system filter and can supply a filter that  performs it own checks and
if desired can delegate to the system filter.
Some thought does need to be designed into the filter supplied as to
its purpose and edge cases.

Thanks, Roger


On 8/23/18 12:19 PM, Weijun Wang wrote:
> But calling getObject(filter) effectively overrides the system filter, is that a problem?
>
>> On Aug 23, 2018, at 11:51 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi Max,
>>
>> Yes, the stream is passed to the readObject method of the classes being deserialized.
>>
>> But that's only a concern during the call to a.readObject() not on the call to setObjectInputFilter.
>>
>> It would be reasonable I think for getObject0 to put a doPriv around the call to a.setObjectInputFilter(filter).
>> Then it would not be necessary to document the security exception nor need for a permission
>> and making it easier to understand.  The Signed/Sealed object should be free to set the filter regardless
>> of the current SM.
>>
>> Roger
>>
>>
>> On 8/23/18 11:14 AM, Weijun Wang wrote:
>>> You mean during deserialization an untrusted object could be created that have a reference to the stream itself?
>>>
>>>> On Aug 23, 2018, at 10:12 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The original basis for the security manager check was to ensure that the filter could
>>>> not be replaced by untrusted code including code in the classes being deserialized
>>>> that have access to the ObjectInputStream.
>>>>
>>>> Regards, Roger
>>>>
>>>> On 8/23/18 10:00 AM, Weijun Wang wrote:
>>>>> This follows the convention of ObjectInputStream::setObjectInputFilter. IMHO, in that case the caller also creates the filter and it's only set on this input stream.
>>>>>
>>>>> Maybe we shouldn't have added the permission check there?
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>> On Aug 23, 2018, at 4:55 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>>>
>>>>>> One thing I am curious about. Is there a reason why getObject(ObjectInputFilter) requires a permission check?
>>>>>>
>>>>>> In this case, the caller is the one creating the filter and passing it in, so the caller can only cause harm to themselves, and the ObjectInputStream is a local variable which is not returned. This method also does not mutate the contents of the SignedObject (or SealedObject) ... so I don't see the risk here. I think you can just wrap ObjectInputStream.setObjectInputFilter in doPrivileged.
>>>>>>
>>>>>> --Sean