Isolation suggestion: landlock

[chrysn]

As I understand from today's workshop, unblob is troubled by libraries and external programs plagued by security issues such as ../.. components in paths. That workshop's discussion showed that chrooting is impractical due to its root requirements.

As an alternative, I suggest you look into landlock, a recent Linux access control mechanism similar to OpenBSD's unveil. This would allow the process to take away its own privileges to the file system (or other system calls), and limit itself to writing to the files that it intends to write to (eg. the JSON report and the unpacking file). Unlike chroot, it requires no elevated privileges; plus it can be configured to run on a best-effort base in case the requirements on a relatively recent kernel are not acceptable.

[vlaci]

We've been thinking about calling the extractors with e.g bubblewrap to achieve something similar. The main reason we did not jump at it is macOS compatibility. You are right that this could be an opt-in feature though.

[vlaci]

FYI, it was very easy to adapt the example from landlock rust crate in unblob-native:

>>> import unblob_native
>>> unblob_native.sandbox.restrict_fs_access_to("/tmp")
Fully sandboxed.
>>> open("/tmp/foo", "w").write("bar")
3
>>> open("./foo", "w").write("bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [Errno 13] Permission denied: './foo'

We could conditionally compile this into the native extension, and according to the readme it fails gracefully.

[qkaiser]

I need to read more about this but looks 🔥

[qkaiser]

I know it's been a while, but we're getting closer to unblob yielding the power of Landlock (see #597 and onekey-sec/unblob-native#11).

Closing this discussion as resolved. Thank you very much for the suggestion @chrysn