We can now create snippets for user mount profiles from interfaces
We did not merge the change doing the creation of the user mount namespace
Initial phase will have ephemeral namespaces for these cases, which last while the application process is alive.
Second phase to follow soon after will persist the user namespaces, and use snap-update-ns to update it dynamically just like everything else today.
Current development is addressing a security concern:
Unlike all the other mounts which snap-update-ns does, the source and the target of these mounts is owned by the user
snap-confine runs as root, so symlinks might trick the system into mounting into the wrong places
Unfortunately the kernel API lacks support for operations via file descriptors, and lacks support for a no-follow flag
The simplistic idea of doing the mount and then checking is not ideal because it creates a window of exploit, and even if right now the application is frozen during the refresh and the namespace is currently hidden, in the future we want to make that namespace persistent. Also the principle of it is in the wrong side of history: do-and-check is bad security vs. don’t do anything dangerous in the first place.
Current plan is to do the mount with a target in a non-accessible location, then verifying, and just then exposing to the world.
One way to verify might be to open the directory, inspect the path associated with the file descriptor to ensure correctness, doing the bind mount, and then comparing that the inode is the same, and finally exposing the target location to the application
The way to expose securely at the final step is to go to the target directory and mount from within after ensuring correctness
Further investigation will take place next week to ensure correctness and safety.
Landing of working final ultra safe version (maybe broken) is after security review takes place, so probably two weeks from now.
Portals
Portals work by allowing confined applications to send messages to the portal
Portals check the identity of the call site and make a decision
Support for snaps was merged upstream but it was malfunctioning
Support for snaps was fixed upstream already, but not released yet
Ubuntu might be able to support the fixed version soon, and Fedora likely has a fast paced schedule on that too; need to coordinate with Debian and others?
How to check if there’s a working version?
Even then, fixed version will take a while to propagate to every place, and will never be seen in some old releases, which makes snaps using that feature incompatible with those. That’s a side effect of API evolution, but we need to understand how best present the situation.
There’s a security concern that needs further discussion: if portals think the snap is actually unconfined, they might fail open. Needs further investigation and impact analysis.
