Mailing list for discussing bubblewrap code

[Alexander Larsson]

On Tue, Jun 15, 2021 at 1:30 PM Marc Gonzalez <marc.w.gonzalez at free.fr> wrote:
>
> On 15/06/2021 12:12, Alexander Larsson wrote:
>
> > On Tue, Jun 15, 2021 at 12:06 PM Marc Gonzalez wrote:
> >
> >> If I understand correctly, it is not appropriate to discuss bubblewrap
> >> here on this ML, and the best place for a discussion would be opening
> >> an issue on the github issue tracker?
> >
> > No, what i mean is that it's not necessarily right to open issues on
> > github unless they are actual bug reports. We have no "right" place to
> > discuss other kinds of things.
> >
> > It's completely fine if you ask on the flatpak list, but its not a perfect fit.
>
> I have a minor remark regarding "global" variables in bubblewrap.c
>
> At the beginning of the file, there is a block of 11 static variables.
>
> Then another block of 25 non-static variables (all the opt_* "globals").
> As far as I can tell, the 25 opt_* are private to bubblewrap.c
> and could (should?) be marked static. What's your take on this?

Generally, bubblewrap is a tiny binary, where the bubblewrap.c file is
the "main" program. In fact, it used to be the only source file, but
some code got broken out, so it wasn't very careful about static:ness
like this. The "right" thing is to mark them static, but it doesn't
strike me as a very important or exciting change.

> >> For some context, I'm trying to use bubblewrap as a black-box sandboxing tool
> >> for an embedded project (multimedia set-top box). We are required to run
> >> third-party code for the various streaming platforms (Prime, Disney, Youtube,
> >> Netflix, etc) and we want to isolate each one "just in case".
> >
> > bubblewrap is a nice tool for setting up a sandbox, but it is very
> > very raw. It's basically a zero-abstraction CLI interface to the
> > kernel apis for  sandboxing. So, you have to know a lot of how those
> > work to use the tool.
>
> I am willing to invest time to understand namespaces and bind mounts.
> (I have been reading up on these concepts for a few weeks.)
>
> I've been told that I can "roll my own" solution, but I don't feel
> comfortable doing that, hoping that a tool such as bwrap would have
> taken care of the most obvious pitfalls.

I would essentially consider using bubblewrap to be "roll my own", as
it doesn't actually have any opinion on how a sandbox should look or
encode much best practices. Still, using it means writing less code.

> One use-case that bwrap does not seem to address:
> bwrap is invoked by root, but runs the sandboxed process as a given
> user, specified on the command-line (unprivileged daemons) along
> with a list of supplementary groups (for access to some devices)
> using setgroups()

bwrap is designed primarily to run as a non-root user, so it doesn't
really do things like this. Anyway, doing that can easily be done by
just switching to the user before starting bubblewrap. We aren't
really interested in adding such root-using features to bubblewrap
itself.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com