Experimental Landlock based sandboxing

[vlaci]

Implementation of #594 together with onekey-sec/unblob-native#11

Having to first create the extraction directory complicates things a lot.
I am unsure what approach we should take here but it can be seen, that the first directory needs somewhat special treatment.

Alternative integration approaches:

• set LANDLOCK_ACCESS_FS_MAKE_DIR on the parent of the extraction root as an escape hatch
• introduce a workdir where extraction takes place one level deeper to achieve simpler code.

[qkaiser]

I would be in favor of option 1 since it's how unblob works. The extraction path provided with -e is where we create the extraction directory so we do need LANDLOCK_ACCESS_FS_MAKE_DIR.

As long as we're clear about the fact that unblob limits itself to the path provided with -e and not the directory within, it's acceptable to me.

[vlaci]

I would be in favor of option 1 since it's how unblob works. The extraction path provided with -e is where we create the extraction directory so we do need LANDLOCK_ACCESS_FS_MAKE_DIR.

As long as we're clear about the fact that unblob limits itself to the path provided with -e and not the directory within, it's acceptable to me.

We need this for the parent of extraction directory:

LANDLOCK_ACCESS_FS_MAKE_DIR: Create (or rename) a directory.

And this for the parent directory of report file:

LANDLOCK_ACCESS_FS_MAKE_REG: Create (or rename or link) a regular file.

The latter seems a bit much to me

[vlaci]

Hehe, this change is incompatible with code coverage measurement :D

 INTERNALERROR>   File "/home/runner/.cache/pypoetry/virtualenvs/unblob-PkeEArhf-py3.8/lib/python3.8/site-packages/coverage/sqldata.py", line 1064, in _connect
INTERNALERROR>     raise DataError(f"Couldn't use data file {self.filename!r}: {exc}") from exc
INTERNALERROR> coverage.exceptions.DataError: Couldn't use data file '/home/runner/work/unblob/unblob/.coverage.fv-az626-878.3677.365646': unable to open database file

[qkaiser]

Two things to do before tagging as ready for review:

• solve the ModuleNotFoundError: No module named 'unblob_native.sandbox' error by properly exposing it
• add unit testing (unsupported platforms, different access checks)

[qkaiser]

onekey-sec/unblob-native#11

[qkaiser]

Will rebase once version 0.1.2 of unblob-native is in.

[qkaiser]

I built the sandboxer example from rust-landlock and it works on qemu-aarch64-static by returning an error:

$ LL_FS_RO="/bin:/lib:/usr:/proc:/etc:/dev/urandom" \
LL_FS_RW="/dev/null:/dev/full:/dev/zero:/dev/pts:/tmp" \
LL_TCP_BIND="9418" LL_TCP_CONNECT="80:443" \
qemu-aarch64-static \
target/aarch64-unknown-linux-musl/debug/examples/sandboxer bash -i
Error: Landlock is not supported by the running kernel.

So the bug is probably in unblob-native or between unblob-native Rust and unblob-native Python. The exception is giving me the same feeling:

where False = isinstance(AttributeError("'int' object has no attribute 'results'"), PermissionError)

[vlaci]

I'll add tests on the rust side as well then :)

[vlaci]

I built the sandboxer example from rust-landlock and it works on qemu-aarch64-static by returning an error:

$ LL_FS_RO="/bin:/lib:/usr:/proc:/etc:/dev/urandom" \
LL_FS_RW="/dev/null:/dev/full:/dev/zero:/dev/pts:/tmp" \
LL_TCP_BIND="9418" LL_TCP_CONNECT="80:443" \
qemu-aarch64-static \
target/aarch64-unknown-linux-musl/debug/examples/sandboxer bash -i
Error: Landlock is not supported by the running kernel.

So the bug is probably in unblob-native or between unblob-native Rust and unblob-native Python. The exception is giving me the same feeling:

where False = isinstance(AttributeError("'int' object has no attribute 'results'"), PermissionError)

Ahh, we need this error check at the end...
https://github.com/landlock-lsm/rust-landlock/blob/94721d26b2fd1151e71bd7a3aa5a43c463a22347/examples/sandboxer.rs#L133-L135

[l0kod]

Ahh, we need this error check at the end... https://github.com/landlock-lsm/rust-landlock/blob/94721d26b2fd1151e71bd7a3aa5a43c463a22347/examples/sandboxer.rs#L133-L135

Please note that kernels not supporting Landlock should not be an error for programs sandboxing themselves, only for sandboxers that must create sandboxes or error out (like this example). It can be a warning though.

[vlaci]

Ahh, we need this error check at the end... https://github.com/landlock-lsm/rust-landlock/blob/94721d26b2fd1151e71bd7a3aa5a43c463a22347/examples/sandboxer.rs#L133-L135

Please note that kernels not supporting Landlock should not be an error for programs sandboxing themselves, only for sandboxers that must create sandboxes or error out (like this example). It can be a warning though.

Yep, unblob itself already just logs the problem, but I like clear failures in tests.
https://github.com/onekey-sec/unblob/pull/597/files#diff-2d4e67217491bddba5546f44b16c52ae6be29d568b52949950866ec5e4c24b0fR92-R95

[vlaci]

Failing build resolved-by onekey-sec/unblob-native#65

[vlaci]

The one thing requires thorough manual testing is keeping exit on CTRL-C and SIGTERM working. Many shenanigans are added for that purpose.

[qkaiser]

@vlaci we're one conflict away from a merge I think :)

[qkaiser]

We need #1013 for tests to run :)