Repository navigation
Conversation
Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
fe0254c to
307aed3
Compare
smcv
left a comment
There was a problem hiding this comment.
I've closed #818 as basically a duplicate of this one, but if you prefer the text from #818, please force-push that commit to this branch as a replacement.
My concern with this (and the whole "Limitations" section, really) is that we can never document every limitation that could make a well-intentioned attempt at sandboxing ineffective: there is always going to be another thing that we didn't think of, or another thing that we assumed nobody would do.
But, if we try to document everything, after putting a lot of writer and reviewer time into it, we're going to have a wall of text that nobody will read, listing a series of corner-cases that usually don't apply; and that would make the section pointless.
The bottom line is always going to be what we said in the "Sandbox security" section:
bubblewrap is a tool for constructing sandbox environments. bubblewrap is not a complete, ready-made sandbox with a specific security policy.
…
Whatever program constructs the command-line arguments for bubblewrap (often a larger framework like Flatpak, libgnome-desktop, sandwine or an ad-hoc script) is responsible for defining its own security model, and choosing appropriate bubblewrap command-line arguments to implement that security model.
Adds a README limitation explaining that writable
--binddirectories remain live and same-filesystem hard links can let sandbox writes modify host files. It recommends using a separate filesystem for writable roots when isolation from host-side changes is required.Closes #813.
Validation:
git diff --check.