3 ms·

This is the minimum options I needed to get it to work: landrun --log-level debug --exec --ro /usr/bin --ro /usr/lib --rw /tmp touch /tmp/foo Personally I don

This is the minimum options I needed to get it to work: landrun --log-level debug --exec --ro /usr/bin --ro /usr/lib --rw /tmp touch /tmp/foo Personally I don't like that --exec would allow binaries in /tmp to be executed as well...

nine_k 2y ago
As a workaround you could create a tmpfs device like /tmp_noexec with noexec flag, and mount it instead of the normal /tmp. But landrun does not (yet?) allow changing the name in directory options :( For added security, I'd create an ephemeral tmpfs disk for each landlocked invocation: obviously the program we're running has no business seeing what other processes may have put to /tmp.
- ranger_danger 2y ago
  > I'd create an ephemeral tmpfs disk for each landlocked invocation And now you've just invented firejail.
  - nine_k 2y ago
    UX-wise, yes. Internally firejail and landrun use different isolation APIs.
    - ranger_danger 2y ago
      Firejail supports Landlock though: https://github.com/netblue30/firejail/pull/6078 https://github.com/netblue30/firejail/pull/6078
qwertox 2y ago
But `landrun --ro /usr/bin --ro /lib --ro /lib64 --rw /path/to/dir touch /path/to/dir/newfile` vs `landrun --ro /usr/bin --ro /lib --ro /lib64 --exec /usr/bin/bash` seems to indicate that `--exec` is only required if the command you're executing then uses an `exec`-call internally, which `bash` would need to be able to fork. So `touch` should not need `--exec`, while `bash` should be able to run anything it can read (including that whitelisted `/tmp`).
- ranger_danger 2y ago
  The former does not work for me, I have to add --exec. I can only assume it's because touch is in /usr/bin and so it needs permission to execute it from there. It seems that using --ro or --rw at all makes --exec also mandatory.
  - Zoup 2y ago
    well yeah you'll need --exec when you want to run binaries (unlike... cat?) I hope landlock adds support to bind --exec to actual directories, that'll be fun!
    - ranger_danger 2y ago
      > you'll need --exec when you want to run binaries well when wouldn't it do that? in what scenario could you even use this tool without needing to execute a binary?
      - Zoup 2y ago
        running cat isn't a --exec for one :)
        ranger_danger 2y ago
        how so? $ landrun --ro /usr/bin cat a [landrun:error] 2025/03/22 23:50:16 permission denied
        Zoup 2y ago
        in this case doesn't have access to "a" wherever it is... $ landrun --ro /usr cat /usr/bin/ls | wc -l 400 executing ls (as in actual binary execution) will require --exec $ landrun --ro /usr ls /usr/bin/ ls: cannot open directory '/usr/bin/': Permission denied $ landrun --ro /usr --exec ls /usr/bin/ list of billions of files note that I don't really love the --exec thingy, if it's not "on" by default it's just for sake of being explicit. Update: there's a bug to limit "file access", which I'll fix asap. Update2: Adding a --exec-path instead to limit executable, it wasn't the best idea to have a global --exec anyway Update3: Have a look at V0.1.4, I think it's far cleaner now.

nine_k 2y ago

As a workaround you could create a tmpfs device like /tmp_noexec with noexec flag, and mount it instead of the normal /tmp. But landrun does not (yet?) allow changing the name in directory options :( For added security, I'd create an ephemeral tmpfs disk for each landlocked invocation: obviously the program we're running has no business seeing what other processes may have put to /tmp.

ranger_danger 2y ago
> I'd create an ephemeral tmpfs disk for each landlocked invocation And now you've just invented firejail.
- nine_k 2y ago
  UX-wise, yes. Internally firejail and landrun use different isolation APIs.
  - ranger_danger 2y ago
    Firejail supports Landlock though: https://github.com/netblue30/firejail/pull/6078 https://github.com/netblue30/firejail/pull/6078

qwertox 2y ago

But `landrun --ro /usr/bin --ro /lib --ro /lib64 --rw /path/to/dir touch /path/to/dir/newfile` vs `landrun --ro /usr/bin --ro /lib --ro /lib64 --exec /usr/bin/bash` seems to indicate that `--exec` is only required if the command you're executing then uses an `exec`-call internally, which `bash` would need to be able to fork. So `touch` should not need `--exec`, while `bash` should be able to run anything it can read (including that whitelisted `/tmp`).

ranger_danger 2y ago
The former does not work for me, I have to add --exec. I can only assume it's because touch is in /usr/bin and so it needs permission to execute it from there. It seems that using --ro or --rw at all makes --exec also mandatory.
- Zoup 2y ago
  well yeah you'll need --exec when you want to run binaries (unlike... cat?) I hope landlock adds support to bind --exec to actual directories, that'll be fun!
  - ranger_danger 2y ago
    > you'll need --exec when you want to run binaries well when wouldn't it do that? in what scenario could you even use this tool without needing to execute a binary?
    - Zoup 2y ago
      running cat isn't a --exec for one :)
      - ranger_danger 2y ago
        how so? $ landrun --ro /usr/bin cat a [landrun:error] 2025/03/22 23:50:16 permission denied
        Zoup 2y ago
        in this case doesn't have access to "a" wherever it is... $ landrun --ro /usr cat /usr/bin/ls | wc -l 400 executing ls (as in actual binary execution) will require --exec $ landrun --ro /usr ls /usr/bin/ ls: cannot open directory '/usr/bin/': Permission denied $ landrun --ro /usr --exec ls /usr/bin/ list of billions of files note that I don't really love the --exec thingy, if it's not "on" by default it's just for sake of being explicit. Update: there's a bug to limit "file access", which I'll fix asap. Update2: Adding a --exec-path instead to limit executable, it wasn't the best idea to have a global --exec anyway Update3: Have a look at V0.1.4, I think it's far cleaner now.