Mailing list for discussing bubblewrap code

[Marc Gonzalez]

On 22/06/2021 11:46, Marc Gonzalez wrote:

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

Take "mount propagation types" (MS_SHARED, MS_PRIVATE, MS_SLAVE, or MS_UNBINDABLE).

AFAIU, these make sense only in the context of mount namespaces? (CLONE_NEWNS)
Hmmm, maybe not. Bind mounts also use the concept.

https://man7.org/linux/man-pages/man2/mount.2.html
https://man7.org/linux/man-pages/man7/mount_namespaces.7.html

SHARED SUBTREES

       After the implementation of mount namespaces was completed,
       experience showed that the isolation that they provided was, in
       some cases, too great.  For example, in order to make a newly
       loaded optical disk available in all mount namespaces, a mount
       operation was required in each namespace.  For this use case, and
       others, the shared subtree feature was introduced in Linux
       2.6.15.  This feature allows for automatic, controlled
       propagation of mount and unmount events between namespaces (or,
       more precisely, between the members of a peer group that are
       propagating events to one another).

       Each mount point is marked (via mount(2)) as having one of the
       following propagation types:


IIUC, before "mount propagation types" were introduced, propagation
type was always MS_PRIVATE?


Another set of random questions:

After calling unshare(CLONE_NEWNS), we're in a new mount space,
with a copy of the mount point list. Is there any way to start
with an empty list? Do we have to remove "unneeded" mounts one-by-one?
(Do these questions even make sense?)
Should these mounts be tagged MS_UNBINDABLE to have them automatically
pruned from the list when we unshare?


It looks like we need 3 calls to mount to sandbox the filesystem:

// 1. change all mount points to private
mount(NULL, "/", NULL, MS_PRIVATE | MS_REC, NULL);
// 2. create the bind mount at dest
mount(src, dest, NULL, MS_BIND | MS_REC, NULL);
// 3. optionally mark RDONLY
mount(NULL, dest, NULL, MS_BIND | MS_REMOUNT, NULL);

I'm wondering what the best-practice advice is here.
AFAIU, bwrap does steps 2 and 3.
The comment also mentions marking RDONLY must be done one-by-one,
apparently MS_REC does not work?

Sorry for the deluge of questions, I'm really confused.

Regards.