Massive bindings that requires more than 9000 args

[freerig]

Hey there, it's about the 9000 args limit!
https://github.com/containers/bubblewrap/blob/d6180f25b164c708b8b0a0d86d6a9642f30cd9a9/bubblewrap.c#L1768C1-L1779

Short issue:
How to bind a massive amount of files, without copying them to a tempfs (I don't want duplicated data)?

The code says I should link them, but in order to symlink them, I would have to bind the src file (which makes me go into the same problem). I could also hardlink it but I use different devices for the files I wanna bind so I get Invalid cross-device link

Context (not essential):
I'm doing a program that sandboxes a Minecraft client with Nix (no need to know Nix at all, this is just to give context). Nix stores all the resources, files, etc... in the Nix store (/nix/store), and so I have this massive amount of assets files in /nix/store. Every asset is in /nix/store, but not everything in /nix/store is an asset.
And so I have the list of assets paths to give to bubblewrap (assets are still located in /nix/store), and it's too big.

[GalaxySnail]

If I understand this post correctly, the 9000-argument limitation is a mitigation of a certain glibc exploit that allows suid executables to be used to escalate root privileges. So I think this limitation may be unnecessary for a non-suid bwrap.

[ambiso]

I also just ran into this and it would be nice to be able to pass more arguments.

Massage the heap using just command line arguments and the environment [src]

As I understand limiting the number of args is defense in-depth mechanism to defend against a buffer-overflow?

Is the mitigation effective? I.e. are there not other ways of massaging the heap (e.g. passing many rules via --seccomp FD)?

As for suid bwrap - what would be the setup here?
A setuid bash script that calls bwrap and allows the user to pass extra arguments to bwrap?

[congwang-mk]

sandlock uses Landlock for filesystem isolation instead of bind mounts, so there's no argument limit — rules are added via landlock_add_rule() syscalls, not CLI args.

# Allow read access to specific Nix store paths (no limit on count)
sandlock run -r /nix/store/abc... -r /nix/store/def... -r /usr -r /lib -w /tmp -- minecraft

For selective access within /nix/store where the list is truly massive, you can also use a dynamic policy to decide at runtime:

from sandlock import Sandbox, Policy

ALLOWED = set(open("asset_paths.txt").read().splitlines())

def check_access(event, ctx):
    if event.category == "file" and "/nix/store" in event.path:
        if event.path not in ALLOWED:
            return True  # deny
    return 0  # allow

policy = Policy(fs_readable=["/usr", "/lib", "/etc", "/nix/store"])
Sandbox(policy, policy_fn=check_access).run(["minecraft"])

No root, no namespaces, no bind mounts.

[swick]

Please stop spamming issues with landlock advertisement.

[smcv]

On #742, now that setuid mode is being removed as too much of a security hazard, @GalaxySnail asked:

Should this check also be removed according to #703?

and @alexlarsson replied:

Honestly, I don't know. Its certainly massively less risky to get an overflow crash if the app is not setuid. But it could also be exploitable to get an unprivileged crash if you somehow control what gets passed to bubblewrap when its used to implement a sandbox.

That said, given the sizes in the google example, if people have problems with 9000 it should definately be possible to bump it way higher, like say 10x and not risk ending up in a heap/stack collision.

[smcv]

if you [the attacker] somehow control what gets passed to bubblewrap when its used to implement a sandbox

In general, our security model would say that in this scenario, the attacker has already won: bubblewrap just does what it's told, so if the attacker can control its arguments, then the sandbox is not going to protect the defender.

But, I could imagine that there could potentially be situations where bubblewrap arguments are generated from a template supplied by the defender, but with the attacker able to control how many arguments are passed (for example if the arguments are constrained to all be subdirectories of /foo, and they're validated to avoid path traversal, but the attacker can control how many subdirectories of /foo they ask for). Would that be a bug in bubblewrap (should limit arguments), or a bug in the "larger" program that is validating/generating the arguments? I don't know.

[GalaxySnail]

Personally I don't think a mitigation for a more than 10-year-old glibc vulnerability in 32-bit userspace would still be relevant today. On the other hand, perhaps we can turn this into a recursion check that avoids stack overflow on typical platforms (such as glibc and musl with the default stack size). For example, there's no need to increase the counter while parsing an --args file:

• bubblewrap/bubblewrap.c

  Lines 1534 to 1544 in 82e79a9

  	p = opt_args_data;
  	while (p != NULL && p < data_end)
  	{
  	data_argc++;
  	(*total_parsed_argc_p)++;
  	if (*total_parsed_argc_p > MAX_ARGS)
  	die ("Exceeded maximum number of arguments %u", MAX_ARGS);
  	p = memchr (p, 0, data_end - p);
  	if (p != NULL)
  	p++;
  	}

BTW, if you have 3000 mounts, you will encounter this performance issue first: #384, but that's a separate topic.

[adammulnix]

I am seeing this limit downstream through OpenAI Codex Linux sandbox runs.

Codex can construct a large bubblewrap command when its workspace/profile expands into many read-only bind mounts. In our VM parity checks, the sandbox proof does not reach the policy assertion because bubblewrap exits first with:

bwrap: Exceeded maximum number of arguments 9000

That turns a runtime sandbox verification into a known upstream gap. The downstream area to look at is Codex Linux sandbox command construction around many --ro-bind entries.

I filed the downstream Codex request here:

openai/codex#22889