Mailing list for discussing bubblewrap code

[Marc Gonzalez]

On 19/06/2021 17:17, Jeremiah C. Foster wrote:

> On Tue, 2021-06-15 at 13:30 +0200, Marc Gonzalez wrote:
>
>> I am willing to invest time to understand namespaces and bind mounts.
>> (I have been reading up on these concepts for a few weeks.)
> 
> As an aside, Michael Kerrisk has a course on the various kernel parts
> that make up the isolation apis (namespaces, cgroups, etc.) that I've
> taken and can recommend. In addition, he's published a great deal of
> documentation on LWN which you may find helpful.[1]
> 
> For the case you mention regarding ownership of the nested containers,
> I would look at cgroups2 which has some logic that controls ownership
> of isolated namespaces and the requisite capabilities for controlling
> the same.
> 
> 1. https://lwn.net/Articles/531114/


Hello Jeremiah,

Thanks for the link. I had in fact stumbled upon this one of Michael's presentations:

https://man7.org/conf/meetup/understanding-user-namespaces--Google-Munich-Kerrisk-2019-10-25.pdf

I must admit that I'm having a really hard time wrapping my head around the
various security concepts in Linux.


For example, take user namespaces. As far as I understand, the intent is to
create an "environment" where an unprivileged user appears to be privileged
*within* said environment. To me, this looks similar to a VirtualBox VM
where I install my own OS, and be root in that VM.

Only I suppose this is much more light-weight, in terms of RAM/CPU?

In any case, our use-case is somewhat different: we're starting long-lived
programs (daemons, I suppose) as root, setting up their environment, and
*dropping* all privileges to prevent any security risk, should a weakness
be found in one of those programs. I don't see how user namespaces are
useful in that situation.


Take another example: bind mounts and chroots. It's not clear to me how
those two concepts relate. To me, they both limit what a given process
can access in the actual filesystem. The bubblewrap source code uses the
word "chroot" but never calls the chroot syscall.

AFAIU, chroot means "the process can't see outside of directory D,
i.e. D becomes the process's root directory". Bind mounts allows
"grafting" different parts of the actual filesystem to a process's
view of its "composite" filesystem. If that is correct, then
bind mounts are in fact a superset of chroot?


I'm still grappling with the various security concepts:
- chroot vs bind mounts
- namespaces (cgroup, IPC, net, mount, PID, user, UTS)
- capabilities
- seccomp
- cgroups
- filesystem permissions + supplementary groups

(My background is performance, not security; I feel mostly like a beginner.)
Some namespaces seem straight-forward, others are much harder to understand
for me.


I had been hoping someone had taken all these concepts and wrapped them
neatly inside a "sandboxing toolbox" to be used by non-specialists such
as myself. The closest projects I could find were
https://github.com/containers/bubblewrap
https://github.com/cloudflare/sandbox

The bubblewrap README mentions related projects:
- firejail
- Sandstorm.io
- runC/binctr

I wonder if the wide array of use-cases means everybody needs a different
solution for their own problem. Meaning I would have to actually code
something myself.

Anyway, thanks to anyone who's read through my ramblings ;)

Regards.