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

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

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

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.

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

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.

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

Fair enough lol

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.

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

TIL. I wish I knew years ago, I've never been happier to have switched.

Still using Chrome for work stuff, since profile management in FF is still pure hate.

what's wrong with `firefox -ProfileManager` and the like or alternatively containers?

I always seem to end up with duplicate profiles, or `about:profiles` refuses to open ("Another copy of Firefox has made changes to profiles.") and on and on with various hiccups and speedbumps. Small annoyances, but profiles on Chrome always Just Work, and the half-dozen times I tried it on FF was always death by a thousand cuts.

It's been a few years, so I'll give profiles another try I guess. Containers likely won't do it since multiple profiles all use the same domain (console.aws.amazon.com being the obvious one).

Containers don't need to auto-open domains. You can simply use them to "color" tabs manually. That should cover your needs!

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

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

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.

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.

True! I had the same feeling.

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.

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

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

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

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.

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!

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

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

how so?

$ landrun --ro /usr/bin cat a

[landrun:error] 2025/03/22 23:50:16 permission denied

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.

--ro /usr does not apply to /usr/bin. change it to --ro /usr/bin and then cat will refuse to run.

it's recursive by default

well it's not working. please try it

give it a try with v0.10: landrun --rox /usr/ --ro /usr/lib ls /usr/bin/

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.

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

And now you've just invented firejail.

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

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

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.

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?

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

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