couldn't `bwrap` be a small shell script around `unshare`?
-
couldn't `bwrap` be a small shell script around `unshare`?
-
couldn't `bwrap` be a small shell script around `unshare`?
@navi@social.vlhl.dev imean yes ? but like . its ok like it is for me , its nice
-
@navi@social.vlhl.dev imean yes ? but like . its ok like it is for me , its nice
@fiore i just learned more in depth how unshare works and i'm just at a bit of a shock, because bwrap is 4.3k lines of c when it basically could be a quite small shell script calling `unshare`, `mount` and that's about it -
@fiore i just learned more in depth how unshare works and i'm just at a bit of a shock, because bwrap is 4.3k lines of c when it basically could be a quite small shell script calling `unshare`, `mount` and that's about it
@navi@social.vlhl.dev imean bwrap has lots of different features and things it can do tho . hell it has overlays n shit too
-
@navi@social.vlhl.dev imean bwrap has lots of different features and things it can do tho . hell it has overlays n shit too
@navi@social.vlhl.dev unsharing things properly is not trivial , so having smth that u know does it the way you want it to be done is nice
-
@navi@social.vlhl.dev unsharing things properly is not trivial , so having smth that u know does it the way you want it to be done is nice
unshare all namespaces, map current user, create a temporary dir and mount a tmpfs on it
on that tmpfs, setup /dev, /proc, /sys, and then do whatever the commandline arguments asked, be it
mount -o bind,ro,mount -o bind,rw,mount -o overlay, etc -- skimming the manpage, all options map to either aunshareflag, amountcommand, or normal coreutils commands (e.g. for --dir and --file)pivot_root into the dir, unmount the old root, drop the capabilities (that allow mounting), exec into the application, done
-
unshare all namespaces, map current user, create a temporary dir and mount a tmpfs on it
on that tmpfs, setup /dev, /proc, /sys, and then do whatever the commandline arguments asked, be it
mount -o bind,ro,mount -o bind,rw,mount -o overlay, etc -- skimming the manpage, all options map to either aunshareflag, amountcommand, or normal coreutils commands (e.g. for --dir and --file)pivot_root into the dir, unmount the old root, drop the capabilities (that allow mounting), exec into the application, done
My experience with shell scripts says that it can't cover the same user case as bubblewrap since bwrap can be suid/setcap if the distribution kernel requires it and being a security component will sooner or later require protection against a race condition (or similar) that is impossible to fix in shell. Aside from that the C code could be made more trimmed, yes.
-
My experience with shell scripts says that it can't cover the same user case as bubblewrap since bwrap can be suid/setcap if the distribution kernel requires it and being a security component will sooner or later require protection against a race condition (or similar) that is impossible to fix in shell. Aside from that the C code could be made more trimmed, yes.
@sertonix @fiore
> later require protection against a race condition (or similar) that is impossible to fix in shell
i'd like examples of what those are, for this specific usecase, because all setup happens before the target untrusted application is even started
> bwrap can be suid/setcap
a thin suid/setcap wrapper can provide that (since unshare itself can't be setuid, that'd be *bad*) if it's really needed, but now a days user namespaces are basically better than setuid -
@sertonix @fiore
> later require protection against a race condition (or similar) that is impossible to fix in shell
i'd like examples of what those are, for this specific usecase, because all setup happens before the target untrusted application is even started
> bwrap can be suid/setcap
a thin suid/setcap wrapper can provide that (since unshare itself can't be setuid, that'd be *bad*) if it's really needed, but now a days user namespaces are basically better than setuid> i'd like examples of what those are, for this specific usecase, because all setup happens before the target untrusted application is even started
I don't know a concrete example, it's just a guess. One might need to open fds to pass around data. In POSIX shell that typically requires fixed fd numbers. If there is C code which wants to pass a fd into the sandbox it might happens to be the same as the one used in the shell code and some data ends up in places it wasn't supposed to.
As far as I can tell you are also assuming a shell to be available in the new user namespace. I have used bwrap in ways where this was not the case.
-
> i'd like examples of what those are, for this specific usecase, because all setup happens before the target untrusted application is even started
I don't know a concrete example, it's just a guess. One might need to open fds to pass around data. In POSIX shell that typically requires fixed fd numbers. If there is C code which wants to pass a fd into the sandbox it might happens to be the same as the one used in the shell code and some data ends up in places it wasn't supposed to.
As far as I can tell you are also assuming a shell to be available in the new user namespace. I have used bwrap in ways where this was not the case.
@sertonix @fiore
> If there is C code which wants to pass a fd into the sandbox it might happens to be the same as the one used in the shell code
in this application, there's no reason to open file descriptors internally in the shell script (e.g. by `exec foo>3` or smth) -- additionally, by all i know, posix shells are not supposed to modify already-open file descriptors passed to it, so all in all passing fds through the shell would work fine
the only moment the shell would interact with fds directly would be to handle `bwrap`s --file argument, for the other fd arguments, unwrap expects a file path, so the shell would have to make a /proc/self/fd/$fd arg, thus not touching them directly
> As far as I can tell you are also assuming a shell to be available in the new user namespace. I have used bwrap in ways where this was not the case.
the shell script is used to build the tmpfs, as mentioned the first post you replied to -- meaning it's launched from the host, it creates the namespaces, and executes the command inside it as the last step
nothing here requires spawning a new shell in the resulting tmpfs root tree, so nothing requires a shell to exist inside the resulting container, *all* the setup is done in the host before chrooting, and the very same thing is true for bwrap -
@sertonix @fiore
> If there is C code which wants to pass a fd into the sandbox it might happens to be the same as the one used in the shell code
in this application, there's no reason to open file descriptors internally in the shell script (e.g. by `exec foo>3` or smth) -- additionally, by all i know, posix shells are not supposed to modify already-open file descriptors passed to it, so all in all passing fds through the shell would work fine
the only moment the shell would interact with fds directly would be to handle `bwrap`s --file argument, for the other fd arguments, unwrap expects a file path, so the shell would have to make a /proc/self/fd/$fd arg, thus not touching them directly
> As far as I can tell you are also assuming a shell to be available in the new user namespace. I have used bwrap in ways where this was not the case.
the shell script is used to build the tmpfs, as mentioned the first post you replied to -- meaning it's launched from the host, it creates the namespaces, and executes the command inside it as the last step
nothing here requires spawning a new shell in the resulting tmpfs root tree, so nothing requires a shell to exist inside the resulting container, *all* the setup is done in the host before chrooting, and the very same thing is true for bwrap@navi@social.vlhl.dev @sertonix@social.treehouse.systems well , cool thing about bwrap chroots is that they are nestable .
-
@navi@social.vlhl.dev @sertonix@social.treehouse.systems well , cool thing about bwrap chroots is that they are nestable .
-
@navi@social.vlhl.dev @sertonix@social.treehouse.systems yea makes sense actually
imean . if u work on a shell reimpl definitely lmk , id love to help out
-
R relay@relay.mycrowd.ca shared this topic
