On dangerous side effects

[pschanely]

CrossHair has a variety of warnings about "don't run this on code with side effects," but having more safeguards would be nice. Starting this discussion thread as a seed for others to weigh in.

For example, CrossHair will pretty readily try the input of "." for shutil.rmtree.

crosshair check is a fairly targeted command, but crosshair watch and IDE integrations enable checking for large swaths of code, where it may be more difficult to know exactly what is going to get triggered.

Some lines of thought:

• Look at monkey patching options like pyfakefs. Possibly this has the added benefit of getting to a place where CrossHair can effectively be used on stateful code. But it is also not completely reliable - it's possible to import and grab functions before pyfakefs can rewire them.
• Maybe a chroot jail? But this won't work on Windows.
• Suggest workflows that run CrossHair as a user without write access to the filesystem.
• Suggest workflows that run CrossHair in a container.
• Don't worry so much. I don't think, for example, Hypothesis does anything special in this space either.

[pschanely]

More OS-level ideas:

• sudo -u nobody crosshair on UNIX
• runas /trustlevel on windows
• windows sandbox can mount data from the host in read-only mode.

[pschanely]

Auditing in PEP578 (python >= 3.8) looks pretty promising as well.

[pschanely]

Update: I am working on some code for the auditing-based approach. It is explicitly insufficient from a security perspective, but seems like it would catch many common accidents.
Maybe a nice compromise between ease-of-use and effectiveness.

[pschanely]

Update # 2: Auditing protections are now in place when CrossHair runs in Python >= 3.8

[pschanely]

One other idea.

We already intercept function calls. In theory, we could detect that a native function is about to be called and compare it to a (very large) set of allowed native functions. This set would need to be user-configurable for 3rd party libraries.

This would be a much more complete answer to the problem (compared to the current protections based on sys.addaudithook), but potentially a more frustrating experience if we block calls needlessly.