RFC: Unpickle user defined classes sent from the parent to the child

[mhartmay]

The parent has other possibilities than doing attacks via malicious messages.
Therefore it's okay to trust the messages from the parent and use unsecure
unpickling methods for those cases.

Note: I'm not very familiar with this codebase, so we should thoroughly review the changes to ensure they don't introduce any security vulnerabilities.

[moreati]

Maybe relevant to #894

[moreati]

The parent has other possibilities than doing attacks via malicious messages.

Very likely, even I can't think of specific methods.

Therefore it's okay to trust the messages from the parent and use unsecure unpickling methods for those cases.

I do not think this conclusion follows from the above premise.

What's your use case or motivation for this?

[mhartmay]

The parent has other possibilities than doing attacks via malicious messages.

Very likely, even I can't think of specific methods.

Therefore it's okay to trust the messages from the parent and use unsecure unpickling methods for those cases.

I do not think this conclusion follows from the above premise.

Hmm can you construct a test case which violates the promise?

Do you know how to write code that allows a child context to call a function in the (direct and indirect) parent context using Mitogen? This could make a great addition to the examples in the examples/... directory.

What's your use case or motivation for this?

It makes the use of Mitogen way more flexible since more complex classes (namedtuple, subprocess.CompletedProcess, ...) and user defined classed could then be used in the guest calls.

[moreati]

The parent has other possibilities than doing attacks via malicious messages.

Very likely, even I can't think of specific methods.

Therefore it's okay to trust the messages from the parent and use unsecure unpickling methods for those cases.

I do not think this conclusion follows from the above premise.

Hmm can you construct a test case which violates the promise?

I can't, but I don't think that justifies lifting the current restriction - particularly by default, for everyone.

I am already wary of Mitogen's use of pickle in security-critical paths. I'm not the original author, and I don't fully understand the design/model. Hence if we are loosening restrictions I think it is up to us to demonstrate it is not introducing new risks, as opposed to saying we con't think of new risks therefore it must be safe.

I might be more open to designs that delegate the decision to end users, but no promises.

General background: I've previously investigated pickle weaknesses https://github.com/moreati/pickle-fuzz, and tried to mitgate some of them https://github.com/moreati/pikl. I've prototyped a "Pickling Registry" for Mitogen master...moreati:mitogen:wip-pickling-registry. I try to keep an eye out for new research, https://iyehuda.substack.com/p/we-may-have-finally-fixed-pythons is on my reading list.