[linsomniac]

I didn't have much luck with one of the readme examples:

    # rm -f /tmp/foo; ./landrun-linux-amd64 --log-level debug --ro /usr/bin --ro /lib --ro /lib64 --rw /tmp touch /tmp/foo
    [landrun] 2025/03/22 10:28:02 Sandbox config: {ReadOnlyPaths:[/usr/bin /lib /lib64] ReadWritePaths:[/tmp] AllowExec:false BindTCPPorts:[] ConnectTCPPorts:[] BestEffort:true}
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /usr/bin
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /lib
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /lib64
    [landrun:debug] 2025/03/22 10:28:02 Adding read-write path: /tmp
    [landrun:debug] 2025/03/22 10:28:02 Applying Landlock restrictions
    [landrun] 2025/03/22 10:28:02 Landlock restrictions applied successfully
    [landrun] 2025/03/22 10:28:02 Executing: [touch /tmp/foo]
    touch: cannot touch '/tmp/foo': Permission denied

Looks very interesting. I'm achieving something somewhat similar by running soeme processes under docker and mounting volumes ro, but could definitely see a usecase for adding landlock to more server processes.

[Zoup]

yeah you are missing --exec there, which feels a bit useless that you have to mention it, but I prefer things explicit and use all LSM can provide, I can imagine cases where --exec isn't really required. like `cat`.

either case have a look at latest release, it's a bit cleaner.

[mikedelfino]

Could you please help me understand why exec is required for this touch example? Is it necessary to actually launch the touch binary? Or touch itself exec()s something else?

[extraduder_ire]

This might be related to needing execute permissions (filesystem x bit) on the directory to modify files within.

[mikedelfino]

Got it. I thought it had to do with execve() syscall.

[ranger_danger]

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...

[qwertox]

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]

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]

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]

> 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]

running cat isn't a --exec for one :)

[nine_k]

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]

> I'd create an ephemeral tmpfs disk for each landlocked invocation

And now you've just invented firejail.

[nine_k]

UX-wise, yes. Internally firejail and landrun use different isolation APIs.

[ranger_danger]

Firejail supports Landlock though: https://github.com/netblue30/firejail/pull/6078

[bastiao]

Would be possible/make sense to use landlock on OCI/containers land?

[codethief]

Syd[0] uses landlock (among many other mechanisms) to containerize applications and provides an OCI-compatible interface.

[0]: https://gitlab.exherbo.org/sydbox/sydbox

[ammmir]

thanks for the link, Sydbox seems like a super cool project, but there's something weird about it: too many links in the README. not on GitHub, and the project that's on GitHub with a similar name hasn't had a commit in 16 years, is it by the same person?

if they can polish up the public facing side of the project, it would instill more confidence.

[sudahtigabulan]

> too many links in the README

In other documents too. And very repetitive.

I don't need a link to Wikipedia every time "PoC" is used. Or to an online man page every time strace(1) is mentioned.

I get it that a documentation can have more than one "entry point", and hyperlinking all occurrences solves that.

But I think assuming certain audience leads to a document that is more effective. You don't explain addition in university-level textbooks, to make it easier to children from primary school.

This product is simply not for people who hear of strace for the first time.

[chuckadams]

Some Wikipedia articles themselves do this, linking every common word in the article, which makes trying to simply highlight a section of text a fun adventure. I ended up at one point making a userscript to strip all internally-pointing links just to make an article more readable (as an addition to an existing script that stripped all the "[citation needed]" and other noise).

Wikipedia needs some notion of "suggested links" that don't become links unless the text is selected or they're toggled globally or some other explicit action. With those, authors could go and link every last word if they like.

[tczMUFlmoNk]

> which makes trying to simply highlight a section of text a fun adventure

Tip: in Firefox, you can hold Alt to drag and select text without triggering links.

[nmstoker]

I thought Wikipedia recommended against overlinking, and on looking it up, they do:

https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Link...

[yellowapple]

Eh. Personally I find it refreshing to see a page err on the side of too many links instead of too few. No need to explain addition in any book if you can just link to the best explanation available.

The bigger issue IMO is that the links seem to be automatically-generated, and the generation is a bit sloppy; for example, the "Syd" links should probably link to the sandboxing technology instead of Pink Floyd's original frontman.

[sudahtigabulan]

> the links seem to be automatically-generated, and the generation is a bit sloppy; for example, the "Syd" links

I dare you, check the git history! (if you care anyway)

It's all manually crafted, with love. From the Shine On You Crazy Diamond badge at the top down to the very last link.

[codethief]

I agree regarding polishing the public-facing side of the project, though I don't find it particularly problematic that it's not on Github.

[ranger_danger]

that looks really cool, but unfortunately without any obvious examples or even a link to documentation, I'm closing the tab and likely forgetting it exists... I would assume many others would feel the same way.

[codethief]

From the README:

> Read the fine manuals of syd, libsyd, gosyd, plsyd, pysyd, rbsyd, syd.el and watch the asciicasts Memory Sandboxing, PID Sandboxing, Network Sandboxing, and Sandboxing Emacs with syd.

I do agree, though, that the docs could be improved.

[bastiao]

True! I had the same feeling.

[opem]

this looks cool, thanks for sharing. they have linked a ctf event as an interactive example, what? XD