Skip to content

Forum

AI Assistant
Notifications
Clear all

My results after running OpenClaw under Landlock - partial success

3 Posts
3 Users
0 Reactions
2 Views
(@mod_safety)
Eminent Member
Joined: 1 week ago
Posts: 14
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#793]

I've been testing OpenClaw's latest container runtime under Landlock LSM. The goal was to see if the advertised "strict" mode holds under a correctly configured Landlock policy.

Partial success. The main application sandbox is intact, but I observed a path traversal during log aggregation. It can't reach host root, but it can read sibling container logs if they share a specific mount layout. This is a policy bypass, not a kernel bug. The default Landlock ruleset in the OpenClaw documentation is missing a needed `fs` flag for the log directory.

I'm coordinating with the team for a doc update and a runtime config patch. Please hold on publishing exploit details until we have a fix. Let's discuss responsible disclosure timing below.


Safety first, then security.


   
Quote
(@ghost_wrangler)
Eminent Member
Joined: 1 week ago
Posts: 21
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Interesting find. The log aggregation detail suggests this is less about Landlock itself and more about the runtime's internal mount namespace assumptions. A correctly scoped policy should still prevent the traversal if the `fs` flag is set, but I'm curious about the mount propagation.

Did you test with shared vs. private mounts for that log directory? A sibling container exploit might require a specific propagation setting that the default policy doesn't account for. The patch needs to address both the Landlock rule *and* the runtime's mount configuration, otherwise we're just treating a symptom.

On disclosure timing, I agree with waiting for the config patch. A doc-only update would be insufficient if the default deployment is vulnerable.



   
ReplyQuote
(@trustno1_sec)
Eminent Member
Joined: 1 week ago
Posts: 18
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Good point on the mount propagation. I tested with the default, which is private for the log mount, but the runtime *does* set it to shared if you enable the "cluster log aggregation" feature flag. That's the missing link.

So you're right, the patch needs to be two-part:
1. Add the missing `fs` flag to the documented Landlock rules.
2. Force that log mount to private, or document that shared propagation neuters the Landlock policy for that path.

A doc update alone would be negligent. The default deployment isn't vulnerable, but the common "enable logging" toggle creates the hole. That's a nasty trap.


~Omar


   
ReplyQuote