.. in capsicum sandbox

[Harikumar Somakumar]

I didn't quite follow the following statement in the paper
 "A single directory capability that only enforces containment by preventing ".." lookup on the root of a subtree operates correctly; however, two colluding sandboxes (or a single sandbox with two capabilities) can race to actively rearrange a tree so that the check always succeeds, allowing escape from a delegated subset".

What does rearranging the tree mean, changing chroots? Could it be explained what sort of collusion (or the simpler case when a sandbox has two capabilities) enables it to break out of chroot jail?

Thanks,

Hari

[Deian Stefan]

They are describing an issue that comes up because the path resolution and access control check are separate from the actual operation (e.g., open) -- if they were atomic this would not be a problem. Concretely, while the path containing ".." may be resolved to something the sandbox is allowed to access, by the time the actual operation is performed, another sandbox that can modify the parent directories may have changed the filesystem tree such that performing the pathname resolution now would produce something that the sandbox may not actually be allowed to access. 

I would suggest looking at section 4.3.2 of the Traps and pitfalls paper -- it's short and you don't really need to read the rest of the paper to understand the example.

[Harikumar Somakumar]

I see. The issue is clear now. Thanks!

--
You received this message because you are subscribed to the Google Groups "Stanford CS240 Winter 2013" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stanford-13wi-c...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.