This project started as a Rust rewrite of landrun, but it has since evolved on its own path. Here's a quick summary of the main differences between runlock and landrun today:
TODO
Landrun started with best-effort as the default but latter made that opt-in. Unfortunately it just means it doesn't really works on older Linux kernel by default, and you need to manually enable best-effort. That, IMHO, makes the user experience confusing and as such runlock is doing the opposite: it's doing best-effort sandboxing by default (which means that if you're using an older kernel you'll have no TCP sandboxing for instance) but warns the user about the limitation.
Unlike the original version of landrun, runlock doesn't even offer an option to disable the best-effort mechanism, because if in practice it'd just mean that the sandbox cannot run on older kernels, and I don't see why anyone would opt-in for an option that makes the program not working on their system…
TODO
A flag (--disable-auto-import) can be used to disable this automatic detection if need be.
TODO That makes it's generally more reliable than the landrun implementation.
If you want to sandbox a script, that iself run a bunch of binaries, it's convenient to pass the list of command that the script will call, and landrun will automatically whitelist the path to their executable file and also the path to their shared libraries if any. In contrast in landrun you must whitelist everything manually on your own.
Even though the sandboxing program's speed itself isn't really important (given that it only affects set-up time, as the actual sandboxing is later being made by the kernel itself with minimal overhead), it seems that landrun adds an overhead that some user find significant enough.
Because runlock is written in Rust instead of Go, it is roughly 2-3 times faster than landrun on my machine, so in the use case where landrun is too slow, runlock may be seen as an improvement. But again, I'm not trying to start a language war here, in practice I strongly believe that the set-up time of the sandbox can be considered negligible. And I'm trying to make runlock better than the original landlock by proving additional features and an interface with better defaults (IMHO), not by claiming that it's immediately better than landrun because “it's blazing fast® thanks to Rust”.
Caveat: the current dependency parsing code of runlock can actually be more expensive at the moment, because it loads a library entirerly before checking if the library is for the right architecture, which can lead to a slowdown if you have both x86 and x86_64 libraries installed and the correct one isn't being loaded first. This is a known bug an will be fixed sooner than later.