couldn't `bwrap` be a small shell script around `unshare`?

[navi@social.vlhl.dev]

@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@brain.worm.pink]

@navi@social.vlhl.dev imean bwrap has lots of different features and things it can do tho . hell it has overlays n shit too

[fiore@brain.worm.pink]

@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]

@fiore@brain.worm.pink

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 a unshare flag, a mount command, 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

[sertonix@social.treehouse.systems]

@navi @fiore

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.

[navi@social.vlhl.dev]

@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@social.treehouse.systems]

@navi @fiore

> 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.

[navi@social.vlhl.dev]

@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

[fiore@brain.worm.pink]

@navi@social.vlhl.dev @sertonix@social.treehouse.systems well , cool thing about bwrap chroots is that they are nestable .

[navi@social.vlhl.dev]

@fiore @sertonix still works here if the shell and such are still in the namespace, then you can nest the same way as bwrap, it's doing the exact same thing

for bwrap you need bwrap and libcap if not static linked, so it's easier with a c program i guess, just not exclusive to it

[fiore@brain.worm.pink]

@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