[12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject
Weijun Wang
weijun.wang at oracle.com
Thu Aug 23 15:14:54 UTC 2018
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
More information about the security-dev
mailing list