Re: Landstrip

Re: Landstrip

[Justin Suess]

On Tue, Jun 02, 2026 at 04:42:51AM +0300, Jarkko Sakkinen wrote:
> I played with an idea could Landlock LSM be used to do conceptually a
> better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
> 
> After some missteps at first I got it pulled together quite well:
> 
> https://crates.io/crates/landstrip
> 
> To see it in action I also have a fork of pi-hashline-readmap plugin,
> which was a cherry-picked test case I wanted to try out given it already
> hooks the bash tool command for compressed output.
> 
> I just thought that this might interest some as Landlock is not really
> over-used kernel feature in "application sense".
> 
> This is a more lower barrier and more failure tolerant to deploy than
> Bubblewrap based container for this use and purpose in my opinion
> at least.
> 
Very cool! Landlock is great for this usecase of application driven
sandboxing.

(just a quick note, the linux-security-module/linux-integrity
mailing lists mostly for kernel development patches, the
landlock.lists.linux.dev list is more for
userspace Landlock topics like this. so I removed the cc for
linux-security-module/linux-integrity and added that list)

I notice there is a seccomp policy for unix sockets in this application.
Although it might not be in your kernel yet, support for sandboxing
named unix sockets with Landlock was recently merged. :)

https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/

Justin

> [1] https://github.com/anthropic-experimental/sandbox-runtime/issues/291
> [2] https://github.com/jarkkojs/pi-hashline-readmap
> 
> BR, Jarkko
> 

Re: Landstrip

[Jarkko Sakkinen]

On Fri, Jun 05, 2026 at 03:19:09PM -0400, Justin Suess wrote:
> On Tue, Jun 02, 2026 at 04:42:51AM +0300, Jarkko Sakkinen wrote:
> > I played with an idea could Landlock LSM be used to do conceptually a
> > better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
> > 
> > After some missteps at first I got it pulled together quite well:
> > 
> > https://crates.io/crates/landstrip
> > 
> > To see it in action I also have a fork of pi-hashline-readmap plugin,
> > which was a cherry-picked test case I wanted to try out given it already
> > hooks the bash tool command for compressed output.
> > 
> > I just thought that this might interest some as Landlock is not really
> > over-used kernel feature in "application sense".
> > 
> > This is a more lower barrier and more failure tolerant to deploy than
> > Bubblewrap based container for this use and purpose in my opinion
> > at least.
> > 
> Very cool! Landlock is great for this usecase of application driven
> sandboxing.
> 
> (just a quick note, the linux-security-module/linux-integrity
> mailing lists mostly for kernel development patches, the
> landlock.lists.linux.dev list is more for
> userspace Landlock topics like this. so I removed the cc for
> linux-security-module/linux-integrity and added that list)
> 
> I notice there is a seccomp policy for unix sockets in this application.
> Although it might not be in your kernel yet, support for sandboxing
> named unix sockets with Landlock was recently merged. :)
> 
> https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/

Thanks for the pointer. My focus has been more in the wiring than inner
shenanigans but soon might be a good time to revisit :-)

I have also Seatbelt FFI and Windows AppContainer profiles are whatever
they call them through Win32 API.

BR, Jarkko

Re: Landstrip

[Jarkko Sakkinen]

On Mon, Jun 08, 2026 at 05:28:39AM +0300, Jarkko Sakkinen wrote:
> On Fri, Jun 05, 2026 at 03:19:09PM -0400, Justin Suess wrote:
> > On Tue, Jun 02, 2026 at 04:42:51AM +0300, Jarkko Sakkinen wrote:
> > > I played with an idea could Landlock LSM be used to do conceptually a
> > > better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
> > > 
> > > After some missteps at first I got it pulled together quite well:
> > > 
> > > https://crates.io/crates/landstrip
> > > 
> > > To see it in action I also have a fork of pi-hashline-readmap plugin,
> > > which was a cherry-picked test case I wanted to try out given it already
> > > hooks the bash tool command for compressed output.
> > > 
> > > I just thought that this might interest some as Landlock is not really
> > > over-used kernel feature in "application sense".
> > > 
> > > This is a more lower barrier and more failure tolerant to deploy than
> > > Bubblewrap based container for this use and purpose in my opinion
> > > at least.
> > > 
> > Very cool! Landlock is great for this usecase of application driven
> > sandboxing.
> > 
> > (just a quick note, the linux-security-module/linux-integrity
> > mailing lists mostly for kernel development patches, the
> > landlock.lists.linux.dev list is more for
> > userspace Landlock topics like this. so I removed the cc for
> > linux-security-module/linux-integrity and added that list)
> > 
> > I notice there is a seccomp policy for unix sockets in this application.
> > Although it might not be in your kernel yet, support for sandboxing
> > named unix sockets with Landlock was recently merged. :)
> > 
> > https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/
> 
> Thanks for the pointer. My focus has been more in the wiring than inner
> shenanigans but soon might be a good time to revisit :-)
> 
> I have also Seatbelt FFI and Windows AppContainer profiles are whatever
> they call them through Win32 API.

I migrated to direct syscalls with Landlock in order to keep in faster
phase.

I'll implement ACCESS_FS_RESOLVE_UNIX support, and run-time detection to
know whether to fall back to a seccomp policy (which is needed still
few years to come).

One LSM I'm not really familiar of and it bothers me a bit is the eBPF
LSM. I'm not exactly sure would it do anything useful/valuable for
me in this project.

And I think Anthropic's app security policy is actually quite nice
and practical. I plan to use this myself when I do find+xargs type
of risky operations :-) It's great with scripts, which kind of
makes sense.

JSON is quite horrible tho so without breaking backwards compatibility
I'll add --format json|yml. In yml-version there won't be bucket
lists for each rule. Instead it will have singular "allowRead" etc.
statements. This is more to use cases where I find it useful :-)

BR, Jarkko

Re: Landstrip

[Mickaël Salaün]

On Mon, Jun 08, 2026 at 09:24:41AM +0300, Jarkko Sakkinen wrote:
> On Mon, Jun 08, 2026 at 05:28:39AM +0300, Jarkko Sakkinen wrote:
> > On Fri, Jun 05, 2026 at 03:19:09PM -0400, Justin Suess wrote:
> > > On Tue, Jun 02, 2026 at 04:42:51AM +0300, Jarkko Sakkinen wrote:
> > > > I played with an idea could Landlock LSM be used to do conceptually a
> > > > better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
> > > > 
> > > > After some missteps at first I got it pulled together quite well:
> > > > 
> > > > https://crates.io/crates/landstrip

Interesting!  FYI, here is a list of other sandboxers using Landlock
too: https://landlock.io/integrations/

Some new ones are missings, including Landstrip, Nono, and Sandlock.
Feel free to open a PR.

> > > > 
> > > > To see it in action I also have a fork of pi-hashline-readmap plugin,
> > > > which was a cherry-picked test case I wanted to try out given it already
> > > > hooks the bash tool command for compressed output.
> > > > 
> > > > I just thought that this might interest some as Landlock is not really
> > > > over-used kernel feature in "application sense".

I'm not sure what you mean by "application sense", there are a few
sandboxers and also apps with built-in sandboxing, but it would be nice
to have more.  This list is not complete:
https://landlock.io/integrations/

> > > > 
> > > > This is a more lower barrier and more failure tolerant to deploy than
> > > > Bubblewrap based container for this use and purpose in my opinion
> > > > at least.

Indeed!

> > > > 
> > > Very cool! Landlock is great for this usecase of application driven
> > > sandboxing.
> > > 
> > > (just a quick note, the linux-security-module/linux-integrity
> > > mailing lists mostly for kernel development patches, the
> > > landlock.lists.linux.dev list is more for
> > > userspace Landlock topics like this. so I removed the cc for
> > > linux-security-module/linux-integrity and added that list)
> > > 
> > > I notice there is a seccomp policy for unix sockets in this application.
> > > Although it might not be in your kernel yet, support for sandboxing
> > > named unix sockets with Landlock was recently merged. :)
> > > 
> > > https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/
> > 
> > Thanks for the pointer. My focus has been more in the wiring than inner
> > shenanigans but soon might be a good time to revisit :-)
> > 
> > I have also Seatbelt FFI and Windows AppContainer profiles are whatever
> > they call them through Win32 API.
> 
> I migrated to direct syscalls with Landlock in order to keep in faster
> phase.

While it's easy to ask an agent to rewrite/fork (part of) such crate,
it's not a good idea for a few reasons, especially the best-effort
approach, backward compatibility, tests...  Anyway, I plan to update the
crate with the latest features this week.  Still, feel free to open an
issue.

> 
> I'll implement ACCESS_FS_RESOLVE_UNIX support, and run-time detection to
> know whether to fall back to a seccomp policy (which is needed still
> few years to come).

You're welcome to contribute to this crate, at least to open an issue
and explain your requirements.  BTW, this crate is designed with
backward compatibility in mind so it already does run-time detection (in
a safe way), you don't need to reimplement it. ;)

> 
> One LSM I'm not really familiar of and it bothers me a bit is the eBPF
> LSM. I'm not exactly sure would it do anything useful/valuable for
> me in this project.

Not sure, but it would requires privileges anyway.

> 
> And I think Anthropic's app security policy is actually quite nice
> and practical. I plan to use this myself when I do find+xargs type
> of risky operations :-) It's great with scripts, which kind of
> makes sense.

Could you please explain this approach?

> 
> JSON is quite horrible tho so without breaking backwards compatibility
> I'll add --format json|yml. In yml-version there won't be bucket
> lists for each rule. Instead it will have singular "allowRead" etc.
> statements. This is more to use cases where I find it useful :-)

FYI, there is a stable/future-proof/flexible format and related crate
(WIP) that supports both JSON and TOML:
https://github.com/landlock-lsm/landlockconfig

> 
> BR, Jarkko
> 

Re: Landstrip

[Jarkko Sakkinen]

On Tue, Jun 09, 2026 at 08:25:08PM +0200, Mickaël Salaün wrote:
> On Mon, Jun 08, 2026 at 09:24:41AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 05:28:39AM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Jun 05, 2026 at 03:19:09PM -0400, Justin Suess wrote:
> > > > On Tue, Jun 02, 2026 at 04:42:51AM +0300, Jarkko Sakkinen wrote:
> > > > > I played with an idea could Landlock LSM be used to do conceptually a
> > > > > better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
> > > > > 
> > > > > After some missteps at first I got it pulled together quite well:
> > > > > 
> > > > > https://crates.io/crates/landstrip
> 
> Interesting!  FYI, here is a list of other sandboxers using Landlock
> too: https://landlock.io/integrations/
> 
> Some new ones are missings, including Landstrip, Nono, and Sandlock.
> Feel free to open a PR.

Sure. Landstrip also maps Anthropic's policies also to Seatbel and
Windows AppContainer ACLs i.e., Landlock is the Linux equivalent.

> 
> > > > > 
> > > > > To see it in action I also have a fork of pi-hashline-readmap plugin,
> > > > > which was a cherry-picked test case I wanted to try out given it already
> > > > > hooks the bash tool command for compressed output.
> > > > > 
> > > > > I just thought that this might interest some as Landlock is not really
> > > > > over-used kernel feature in "application sense".
> 
> I'm not sure what you mean by "application sense", there are a few
> sandboxers and also apps with built-in sandboxing, but it would be nice
> to have more.  This list is not complete:
> https://landlock.io/integrations/

It might be just my ignorance, I'm truly sorry :-) I usually get
interested on topic when I have first hand need on it and Landlock was
just size-fit for mapping ASR style JSON policies.

> 
> > > > > 
> > > > > This is a more lower barrier and more failure tolerant to deploy than
> > > > > Bubblewrap based container for this use and purpose in my opinion
> > > > > at least.
> 
> Indeed!
> 
> > > > > 
> > > > Very cool! Landlock is great for this usecase of application driven
> > > > sandboxing.
> > > > 
> > > > (just a quick note, the linux-security-module/linux-integrity
> > > > mailing lists mostly for kernel development patches, the
> > > > landlock.lists.linux.dev list is more for
> > > > userspace Landlock topics like this. so I removed the cc for
> > > > linux-security-module/linux-integrity and added that list)
> > > > 
> > > > I notice there is a seccomp policy for unix sockets in this application.
> > > > Although it might not be in your kernel yet, support for sandboxing
> > > > named unix sockets with Landlock was recently merged. :)
> > > > 
> > > > https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/
> > > 
> > > Thanks for the pointer. My focus has been more in the wiring than inner
> > > shenanigans but soon might be a good time to revisit :-)
> > > 
> > > I have also Seatbelt FFI and Windows AppContainer profiles are whatever
> > > they call them through Win32 API.
> > 
> > I migrated to direct syscalls with Landlock in order to keep in faster
> > phase.
> 
> While it's easy to ask an agent to rewrite/fork (part of) such crate,
> it's not a good idea for a few reasons, especially the best-effort
> approach, backward compatibility, tests...  Anyway, I plan to update the
> crate with the latest features this week.  Still, feel free to open an
> issue.

I'm not sure if I fully understand this.

I modified my client to temporarily use syscalls with the plan to return
back using it as soon as it has all the features.

It is only small portion of the implementation so it really is not a big
deal. There's also Window and macOS.

I.e. it is internal code for the client not a sloppy fork and I can
do git revert  + integration once there is the feature available.

I have direct FFI also on macOS and Win32.

> 
> > 
> > I'll implement ACCESS_FS_RESOLVE_UNIX support, and run-time detection to
> > know whether to fall back to a seccomp policy (which is needed still
> > few years to come).
> 
> You're welcome to contribute to this crate, at least to open an issue
> and explain your requirements.  BTW, this crate is designed with
> backward compatibility in mind so it already does run-time detection (in
> a safe way), you don't need to reimplement it. ;)

I can contribute the ACCESS_FS_RESOLVE_UNIX unless it is on your queue.

> 
> > 
> > One LSM I'm not really familiar of and it bothers me a bit is the eBPF
> > LSM. I'm not exactly sure would it do anything useful/valuable for
> > me in this project.
> 
> Not sure, but it would requires privileges anyway.
> 
> > 
> > And I think Anthropic's app security policy is actually quite nice
> > and practical. I plan to use this myself when I do find+xargs type
> > of risky operations :-) It's great with scripts, which kind of
> > makes sense.
> 
> Could you please explain this approach?

How I use Landlock or how ASR policy works? I initialize Landlock with
a recursive traverse to get a policy that snapshots nicely the current
state of directory tree.

> 
> > 
> > JSON is quite horrible tho so without breaking backwards compatibility
> > I'll add --format json|yml. In yml-version there won't be bucket
> > lists for each rule. Instead it will have singular "allowRead" etc.
> > statements. This is more to use cases where I find it useful :-)
> 
> FYI, there is a stable/future-proof/flexible format and related crate
> (WIP) that supports both JSON and TOML:
> https://github.com/landlock-lsm/landlockconfig

I'm specifically doing cross-platform implementation to substute ASR
with a better run-time.

> 
> > 
> > BR, Jarkko
> > 

BR, Jarkko

Re: Landstrip

[Jarkko Sakkinen]

On Wed, Jun 10, 2026 at 12:41:03PM +0300, Jarkko Sakkinen wrote:
 I'm not sure if I fully understand this.
> 
> I modified my client to temporarily use syscalls with the plan to return
> back using it as soon as it has all the features.
> 
> It is only small portion of the implementation so it really is not a big
> deal. There's also Window and macOS.
> 
> I.e. it is internal code for the client not a sloppy fork and I can
> do git revert  + integration once there is the feature available.
> 
> I have direct FFI also on macOS and Win32.

And I'm obviously returning back to your crate in future. No intention
to maintain syscall wrappers in long-term  but right now just for
testing stuff it was useful temporal solution.

For the spec I'm mapping against see:

https://github.com/anthropic-experimental/sandbox-runtime

I saw the code and realized that it does not have anything for Windows
and Seatbelt and Bubblewrap do not pair too well so I decided to make
a fully parametrized version of it so that it could be swapped as
internals for ASR.

I don't have Claude Code installed on any of my machines but since that
policy has high spread it seemed like worth of focusing into as an app
sandboxing policy. I.e. probably could be used in most of coding agents.

So.. I don't think there's any problem here really.

BR, Jarkko