I’m a newcomer, but I’m going to jump in on this one
- The <app> provides a mechanism to <action: print>.
- Snaps break this <action: print> mechanism by default.
- Non-trivial exercise for users to fix the snap’s functionality today.
- I expect this app to do <action: print> based on <my subjective experience of what I have done in the past or the security properties I desire in this snap>.
- I value <security|usability> over this [perceived] loss in <usability|security>.
What are the threat vectors?
- That a malicious inkscape snap will package a CUPS exploit?
- That inkscape is compromised (say via malicious image) and can then perhaps pivot with a CUPS exploit or otherwise abuse the interface?
So what are the options?
(Option 1) Auto-Connect
Usability: Win for everyone.
Security: Requires second vulnerability to break confinement (the scope of this request is the attack surface of CUPS).
(Option 2) Deny Auto-Connect
Usability: Fail for subset of users.
Security: Snap version is “secure”. Some users will switch to lesser secure options (i.e. deb and rpm packages) which may in fact harm security posture.
Another anecdotal story
I come from a background where security nearly always trumped usability. There is a real concern with security-savvy developers that prioritize security over all else, because they know how to work around it when it gets in their way. The problem is that we sometimes lose sight of the practical impacts of our decisions, which often actually reduces effective security because users will workaround the problem themselves with a way that has zero regard for security.
Strong, hard-to-remember password complexity requirements lead to pattern passwords, post-it notes, etc.
Will just turn off confinement altogether (see hundreds of blogs posts / HOWTOs that permanently disable SELinux for the user to perform some action in which SELinux was getting in the way, etc.)
In this case, they will turn to use a less-secure option because “it just works”. Like
apt-get install inkscape. Which, ironically, likely presents a negative long-term effect on the security posture of our users if we choose Option 2.
Users install GUI snaps for convenience of using the application. Some of those users may appreciate the security benefits its packaging format provides. I think it’s up to us (the snap community) to improve security without negatively impacting usability:
UIs to allow the user to toggle confinement options, etc.
Run-time prompts “Do you want to allow this snap to print? [Always | This Time Only | Never]”
Snaps are effectively competing with more usable options. If snaps disrupt the user experience, snap adoption will suffer. Usability needs to be on-par, or as close to par as possible.
Raising the bar for security is a good thing. But there needs to be an actionable path to point towards so it can be done in manner that doesn’t negatively affect the user. If we can get that story straight, we can start declining requests without any of this contention.