I’m seeking advice/opinions as to whether it would be acceptable from a security perspective to all the read: "all" attribute to the home plug for browser snaps (chromium and firefox), and request auto-connection.
The use cases are being discussed in this bug report.
@reviewers, what do you think?
I’m wondering how this interacts with the XDGp backend; on Ubuntu 22.04, I’d imagine if the user disconnected the home interface entirely, this would force the XDGp file picker to attempt to proxy it in $XDG_RUNTIME_DIR/doc, where because the AppArmor restriction wouldn’t apply, it may actually work.
If this is the case, then for users from earlier versions of Ubuntu / earlier versions of XDGp, it’s a regression, because in 20.04 for example, all files in $HOME end up in $XDG_RUNTIME_DIR/doc as the file picker backend doesn’t integrate with Snap fully in that release.
Granted I’m not a reviewer, but IMO it’s not the intention of the home interface to restrict access they’d otherwise already have without the interface, so IMO the read: all attribute makes sense to avoid what’s otherwise a regression (assuming that regression exists! I’m currently away from Linux machines to test with!)
Tl;Dr it’d be weird if they could access root owned world readable files outside $HOME but not in it, but whether that is currently the scenario, I’m unsure.
Anyway, as a community opinion regarding Firefox and Chromium explicitly, I’m all for it.
So the bug report links to Interface auto-connect request for the universal-update-utility snap (home; read: all) as precedence for this - but note that is the reverse case - a snap which is intended to be run as root which then wants to access a users own files in their own home directory - and that is the common use-case / pattern for that snap.
However in this case we are talking about a snap wanting to access root owned files in their own home directory - something that I would say is a lot less common. Also if we were to use read: all this means that in older versions of Ubuntu where shared access to home directories is the norm, then other users would not be blocked by AppArmor from reading the files of a given user (since normal DAC permissions would allow it).
However, that perhaps is the expected model that sysadmins / users may have anyway (ie if they are aware of the permissive home dirs in older Ubuntu releases then they may expect this behaviour) so perhaps the current owner restriction on home would then be more surprising.
So I am in 2 minds about this - I would welcome more input from the community, but at this stage I would err on the side of conservatism and assume this is a pretty niche use-case and hence not necessarily worth the trade-off.
That’s a very powerful point. It’s also unfortunate that when the change to private-by-default home directories happened, it only effected new installations, not existing installations. Given the expected lifespan of hardware these days, and the upgradability from one release to the next, it’s likely that there’d be a significant number of users who still have public home directories for years to come even on newer releases.
I personally think I would consider changing my previous opinion with that context, as I was only evaluating it from the perspective of a single user machine and presuming private home directories. As a community, we force people to adapt to far worse workarounds than running chown on files for much more common usecases. Degrading the security for everybody to improve the situation for a select few balances unfavourably, unfortunate as it is.
For me, personally, I’d argue that browser snaps shouldn’t have the home interface at all and instead use the desktop portal to provide access to files in users’ home folders. IMO that is the direction that every snapped application that is able to should be moving (yes, I appreciate there are some apps that aren’t able to do so, such as every non-desktop snap and any desktop snap that includes an app that is unable to support the portal due to being old code in a dead project or closed source - for those applications the home interface should still be used).
But don’t Firefox and Chromium use the portal?
I see the desktop interface connected and GTK_USE_PORTAL=1 in their environments. Judging by https://snapcraft.io/docs/xdg-desktop-portals, I’d think nothing is missing.
Still I can reproduce the issue for both.
The portals are a matter of luck, they need to be installed in the desktop environment, you have no control over them …
If you run on top of i.e. a plain openbox session you likely don’t have them around …
In these cases you still want the home interface to be connected to be able to access files if needed … it would be cool if snapd could detect the existence of portals and automatically connect it accordingly though.
I agree, that would be really cool - that would allow us a seamless upgrade path for making the home interface non-automatic unless the portals aren’t running.
If you run on top of i.e. a plain openbox session you likely don’t have them around …
Yes, I use a plain window manager and was already bitten by this in the past, but in a plain Ubuntu session (as started via GDM) I still cannot open (via Ctrl+O, at least) a file owned by root; Chromium says
Access to the file was denied
The file at file:///home/nteodosio/asciidoc is not readable. It may have been removed, moved, or file permissions may be preventing access.
but at this stage I would err on the side of conservatism and assume this is a pretty niche use-case and hence not necessarily worth the trade-off.
I have another scenario here, current, that results in files in $HOME not owner by the user: creating VMs off of iso images you downloaded.
libvirt has this (annoying? buggy? default at least) behavior of changing the ownership[1][2][3] of the ISO files it uses to boot a VM from.
This is done by the libvirt daemon, which runs as root, and can do such a thing. If you have that ISO image in your home, you won’t own it anymore by default. If you then happen to want to read that file with your browser for whatever reason, you would hit the bug this topic is talking about.
TBH, I’m also surprised about this snap behavior. It sounds like it’s a shortcoming of the profile that it cannot distinguish a file in my home from a file in another user’s home, if I understood it correctly.
I can think of another case where a root owned file would end up in a non-root user’s home, but I can’t think of a use case for the browser wanting to access that file: ~/.ssh/authorized_keys, to block adding new keys (but that sysadmin apparently doesn’t know about AuthorizedKeysFile in sshd_config).