tend to agree that the use of owner on the home interface in snapd is problematic since the semantics of owner essential mean checking that the user id of the process opening the file is the same as the user id of the owner of file.
that was intended
It doesn’t support extended attributes / ACLs and it doesn’t support checking the group either. So this means that there will be cases that files that should legitimately be able to be read by the process end up getting blocked by AppArmor.
again intended. And I will quibble with your use of legitimate. The point was to make it so the user (or a rogue process run by a given user) couldn’t just change access permissions for what the snap can see without going through a privilege barrier to snap. That is to snap connect was envisioned as the way that files beyond the user’s own files should be added and yes that would require a new interface. If snap is supposed to be in charge of permissions then the only legitimate way to change permissions is via snap, and the snap interface should heavily imply what is allowed.
I would be very careful with this proposed change because you are in fact changing the privilege model, allowing other users to influence the snap in a way that has previously been denied. This changes a security assertion that has been part of every snap review, and should require a re-evaluation of all snaps from a security stand point.
Making non-user owned files accessible by default opens up snaps to cross user attacks in a way that wasn’t previously possible. Is it likely on today’s systems, not really but it is a change in security posture that needs to be evaluated. One reality is that most users don’t actually understand cross user permissions and attacks, its a corner that is better to just close off and only open up when necessary.
suspect this restriction was added due to the fact that AppArmor doesn’t actually know the users real home directory, ie it defines HOME=/home/* (ie. any rule which references the @{HOME} variable grants access to those files in any user’s home directory - and so then the use of owner means that owner @{HOME} in AppArmor is then restricted to only files owned by the user - which more closely approximates their actual HOME directory (and not everyone elses).
this was part of that, and part of the reason the real home dir work hasn’t been prioritized (it is on the roadmap), and yes HOME should only allow files within the users HOMEDIR not the pattern it does today. But no it is not the only reason, it really was about restricting cross user content, and blocking said influence. snap was trying to break away from traditional unix, and move to a more confined android/ios style application confinement. Again content that isn’t the users content within their home should actually require a different interface under this model.
However as @zyga said, we still have DAC which would then block such access (unless other users have explicitly opted in to making their files readable OR they installed Ubuntu before we introduced private home dirs in 21.04). Which means that if we remove the owner attribute from the home interface in snapd (or say grant the use of read-all to a particular snap) then this will now open up the possibility that a snap is able to read files owned by other users.
snap existed before that change, and a lot of users inherit that behavior still
But this is no different than that user directly reading those same files and providing them to the snap etc. So I do not think there is a huge risk here
there is a difference, and there is a risk. Whether its acceptable is a different question. Personally I don’t think that the HOME interface should allow access to files belonging to another user. That is clearly a different security semantic than access to your own files. I think it should require a different interface.
Personally, I feel we lose more in terms of usability by the use of owner for home in snapd than we gain for security/privacy - however I don’t have enough knowledge of the history here. Perhaps @jjohansen or maybe even @jdstrand could weigh in with some historical context around the use of owner for the home interface?
snap has always been about trade-offs in usability vs security. Trying to move to a more secure application world. I am not opposed to adding the ability to allowing access to none user owned files within a users HOME but I think making it part of HOME interface is a mistake. Not only does it significantly change the semantics of an existing interface it does reduce the security. Files owned by another within your HOME is a different use case and as such it should get a different interface to call out this unique situation.
owner in home means you don’t have to think about cross user attack scenarios when reviewing, dropping it means you need to be aware of it, and consider it for every review.
