Comment 2 for bug 2044335

So I've managed to get it to work, as seen below:

```
zyga@novigrad:/var/lib/snapd/apparmor/profiles$ sudo /usr/lib/snapd/snap-discard-ns canonical-livepatch
zyga@novigrad:/var/lib/snapd/apparmor/profiles$ canonical-livepatch.bash
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/local/share/doc /usr/local/share/doc none bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/local/share/doc" because it would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/gimp/2.0/help /usr/share/gimp/2.0/help none bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/gimp/2.0/help" because it would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/gtk-doc /usr/share/gtk-doc none bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/gtk-doc" because it would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/libreoffice/help /usr/share/libreoffice/help none bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/libreoffice/help" because it would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/xubuntu-docs /usr/share/xubuntu-docs none bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/xubuntu-docs" because it would affect the host in "/var/lib/snapd"

BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/var/lib/snapd/apparmor/profiles $ stat /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz
  File: /usr/share/doc/linux-image-6.5.0-14-generic/changelog.Debian.gz
  Size: 6918 Blocks: 16 IO Block: 4096 regular file
Device: 10302h/66306d Inode: 23994178 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-12-10 10:17:53.000000000
Modify: 2023-11-14 13:47:15.000000000
Change: 2023-12-10 10:17:54.000000000
```

The "would affect host" messages are there bacause snap-update-ns is refusing to create directories that are missing on the host (there's no xubuntu-docs in my system, for example) but IMO this is the correct mode of operation.

There's only one problem now: the reason we didn't do this originally, is that the apparmor permissions are somewhat strong (to say the least). Having said that, snap-update-ns is also called without the sandbox, so perhaps the whole premise was too optimistic. The sandbox is really tricky with path-based rules and chroot/pivot root/bind mounts, to the extent that one could argue for inode level permissions instead.

The diff is:

zyga@novigrad:/var/lib/snapd/apparmor/profiles$ diff -u snap-update-ns.canonical-livepatch{.orig,}
--- snap-update-ns.canonical-livepatch.orig 2024-01-16 10:54:33.491167418 +0100
+++ snap-update-ns.canonical-livepatch 2024-01-16 10:58:17.115343785 +0100
@@ -430,4 +430,19 @@
   mount options=(bind,remount,ro) -> /boot/,
   umount /boot/,

+ # Writable mimic over / - extra permissions generalized
+ "/**" rw,
+ "/tmp/.snap/usr/**" rw,
+ mount options=(rbind, rw) "/**" -> "/tmp/.snap/**",
+ mount fstype=tmpfs options=(rw) tmpfs -> "/**",
+ mount options=(rbind, rw) "/tmp/.snap/**" -> "/**",
+ mount options=(bind, rw) "/tmp/.snap/**" -> "/**",
+ mount options=(rprivate) -> "/tmp/.snap/**",
+ umount "/tmp/.snap/**",
+ mount options=(rprivate) -> "/**",
+ umount "/**",
 }

Not terrible, not great.

I would say that if we detect that mimic over / is needed, we could emit something like that into snap-update-ns profile for the snap.

Alex, do you think this is an acceptable solution from the security point of view?