The alternative is to expose that vulnerability for everyone using the snap by default, is that what you’re advocating for?
Yes. I think the user inconvenience of having to manually connect this snap for a piece of core functionality cannot be justified by the scale of the threat, when taken in the context that the snap can autoconnect the
x11 interfaces already. Compared to other snaps in the store I am reassured that:
- the upstream can be trusted to not abuse the interface
- the snap packager can be trusted to not abuse the interface
cups-controlinterface is hard to be damaged by accident from a programming error.
On the other side of the coin:
- the program takes and processes untrusted user input. It is entirely credible that a maliciously crafted image file could compromise the program. It is conceivable there could be a chain of compromises which could abuse the
But even if this was not connected the
x11 interfaces are connected and ripe for abuse.
At present, if I install any snap from the store I’m forced to accept that it can read, write, modify or delete the majority of files in my home directory, communicate with a remote server and eavesdrop on my keyboard input to other x11 applications by default. Asking me to manually connect a printing interface for a trusted image creation application from a trusted upstream source and packager seems like rearranging the deckchairs on the Titanic. The benefits to me, as a user, are minimal in this context. I firmly believe the user convenience of autoconnecting this interface for this snap outweighs the small security risk.
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.
As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.
For example, to request <interface> auto-connect:
- Is application publisher considered trusted by the Snap Store?
<instructions on how to become one>
- Has publisher agreed that they are in accordance to with the <access control policy for authentication keys which can push to store>?
This agreement would help minimize the risk that an unauthorized user can obtain the keys to push an unauthorized <snap> version to the store. It may include consequences if it is discovered that the policy is not adhered to.
- Does the snapcraft recipe perform a repeatable build in accordance to <version policy>?
This could be useful to automate validation of builds and provide an audit trail in case of abuse.
- Does the requested auto-connect interface enable a feature that a reasonable user would expect to work?
That is, does the non-snap version expose this functionality to the user?
- Are there alternatives to using the requested interface that do not impact “reasonable user” functionality?
- Are the alternative(s) documented?
- Is this request intended to be temporary?
- Has publisher agreed on path towards this implementation?
- Has publisher documented grievance on the recommended alternative approach(es)?
- Is this application documented as a core, or security-critical snap?
Is there a documented reason to ensure this application is as hardened / locked down as possible for system security reasons? Presumably this would make the case harder to get auto-connect.
While I appreciate the added information, it hasn’t changed anything wrt my opinion. My opinion isn’t the only one of course and if you look back, I asked for an architect to get involved to potentially overturn the vote.
You provide a lot of reasonable points for usability and removing developer friction (which were acknowledged prior here and in other topics requesting cups-control), but you didn’t acknowledge the importance of the user’s voice in auto-connetions (to connect or not is dictated by snapd (the base declaration), the store (snap declaration) and the user (manually connect/disconnect) or acknowledge that this interface allows configuring printers which is beyond the scope of printing and what inkscape specifically needs. There seems to be a disconnect that this is about security trumping usability. snapd is a new system that is designed for usability, security, reliability, predictability, etc. CUPS does not currently have snap-integration such that it will allow only printing to snaps and so granting inkscape auto-connect, and by extension the ability to configure printers, might provide usability but is unexpected, which degrades security and predictability. Importantly, developers are in full control of guiding the users to provide a better user experience; inkscape is in a position to detect that the interface is not connected and tell the user what to do (indeed other snaps do exactly this), but apparently it still doesn’t do this.
If there was an interface that allowed just printing, then I would vote to auto-connect it (indeed, there is: the desktop interface that allows access to Portals). You said that snaps are competing with more usable options. You are perhaps referring to flatpak which allows access to the portal by default, not the CUPS socket. Snaps also have access to Portals and if they still aren’t working, someone should fix that.
Also keep in mind that all the reviewers attempt to consider your various points and more when voting and we attempt to be consistent and consider prior votes when voting on new snaps. The problem AFAICS with inkscape in particular is that people landed on different sides on if printing is core functionality in inkscape. There are reasonable arguments on both sides. The majority felt that it wasn’t core enough to outweigh diminishing the user’s voice and the predictability and security of the system. This vote has proved contentious so I asked architects to weigh in (cc @pedronis and @niemeyer).
There are many paths forward:
- inkscape could immediately improve the experience and detect if the resource is available and guide the user to the snap-store GUI or terminal command, like other snaps do
- an architect could overrule the vote and grant a snap declaration to inkscape for cups-control
- snapd could make it easier for snaps to detect if interfaces are connected
- snapd could provide APIs for the application to request a connection prompt
- the printing portal should be made to work if it still isn’t available, and inkscape to use it
- snapd/the system could provide a contextual prompt when the cups socket is accessed
- CUPS could be modified to be made snap-aware (eg, only allow printing if a new ‘cups-print’ interface is connected)
There is Process for aliases, auto-connections and tracks which discusses the procedure. Unlike with classic and base snaps which have formalized criteria, interface auto-connections are not codified because each request is unique and subjective and we want to maintain flexibility for change and new thought. That said, all the reviewers consider prior votes for similar requests which can be shown through forum research.
Great points, thank you for sharing Jamie ! Very informative.
As far as other “more usable options”, I wasn’t quite narrowly suggesting flatpaks. I’m inclusive of any option for a user to obtain their software, but the bar is probably best set by the OS’ native packages (In Ubuntu’s case, the debs from the apt mirrors). If it works in the apt repositories, a user would (rightfully) expect it to work as a snap, particularly if the software center prioritizes the snap version over that found in the apt repositories.
As you suggest, there plenty of routes in which things may be improved. There has clearly been an incredible amount of amazing work done by the snap community to get usability as great as it is, across a massive range of projects. It truly is impressive. I’m personally advocating that if none of the technical solutions are immediately available in this case, perhaps we work with the inkscape community to find the optimal path for all parties going forward. In the meantime, an auto-connect does not seem unreasonable given the alternative (frustrated users, perhaps ending up using a wholly unconfined deb, and perhaps worse yet:
apt remove gnome-software-plugin-snap or whatever post they come across on how to disable snaps).
I don’t think anyone here wants to see negative community feedback associated with snap packages breaking expected application behavior. If they decide that snaps aren’t worth the hassle, they’ll resort to another option. I know I have spent plenty of hours debugging why certain snaps aren’t working as intended - I don’t think that’s fair to expect that of our users (even if it’s just one short google search away)! Especially when we have a viable option on the table.
Anyways, enough from me. Have a great weekend!
I read about 40% through this useless argument page. I abandoned Corel Draw and my VirtualBox running Windows 7 so that I could switch to Inkscape. When I started seeing how versatile Snap was I decided to install it on my new laptop using Snap. After weeks of scratching trying to get printing working, and finally coming to this page, I have decided that the people who make the decisions don’t care about the needs of the people who actually use the product.
I will revert back to install Inkscape the old fashioned way, and will slowly migrate ALL my apps back to the old APT system, which never failed me.
My work centers around designing stuff, then printing it to show the partners and get approval. Now I have to print to a pdf, then open the pdf in another app just so I can print it, and if I find anything wrong with the output product, I have to do it all again… it’s like slavery with an extra step.
In the words of Cartman “S**** you guys, I’m going home!”
we have now plans to implement
snapctl is-connected PLUG|SLOT
we have discussed this option for later as well, it would tie into some form of “auto-connection: prompt” (not actual syntax) feature. Then the snap would have some
snapctl command to prompt and possibly get the connection if the user agreed.
Hi folks. We knew when we started on sandboxing that future facilities would enable more fine-grained access control. It seems in this discussion we have made perfect the enemy of good. Giving Inkscape access to pprinting makes sense - it’s a design program, and paper copies are a normal part of the workflow there. Can I ask that we give Inkscape printing access now, while planning to offer more fine-grained facilities and saying clearly that we will expect maintainers and upstreams to do the work on their side when we have those facilities?
In light of Mark @sabdfl’s comment, if this is granted, it might be worth revisiting the decision on the same request for printing capability for GIMP and also allow @hellsworth to request it for Glimpse.
This would be excellent. I’ve encountered Glimpse users wanting this autoconnect in Glimpse too.
@sabdfl as architect has said to grant this, thus overruling the vote provided that “we will expect maintainers and upstreams to do the work on their side when we have those facilities”.
@ted - you’ve stated wrt to portals that “an application can use portals to print if they’re on Ubuntu 18.10 and have all the portals installed. They’re not in main in 18.04 and not even in 16.04, much less 14.04 and the other distros that snaps claim to support. Until portals are a dependency of snapd applications can’t depend on them being there, so we’re forced to deal with things like cups-control.” Considering @sabdfl’s expectation if granting this, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
@Wimpress - can you comment on making the printing portal more widely available for (at least) Ubuntu 18.04 and forward?
@daniel - with GIMP as a design program, you are stating that paper copies are a normal part of its workflow? If so, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
@hellsworth - with glimpse-editor as a design program, you are stating that paper copies are a normal part of its workflow? If so, do you plan to move to portals (or another suitable API if it becomes available) when it is more widely available?
Yes, which would also allow us to drop the
removable-drives interfaces. We’ve investigated what is needed there and expect that the unreleased (at time of writing)
gnome-3-3 extensions will have the version of GTKmm needed to support portals. I’ve currently switched the snap in the development branch of Inkscape over to using that gnome base using the candidate snapcraft.
If I can do that as a Snap package maintainer, and not an upstream developer (i.e. with only changes to the snap packaging without changing upstream’s code) then sure, I’d love to support portals in GIMP. If I cannot do it without modifying GIMP itself, then no, I will not add support.
Basically, I am not happy with carrying and maintaining a delta from upstream.
Granting auto-connection cups-control to this snap. This is now live.
As an aside, thank you for working with us while we refine our processes.
FYI (cc @pedronis), I’ve also adjusted the ‘cups-control’ portion of Process for aliases, auto-connections and tracks to state “or design programs where printing is an expected part of the workflow. Granting requires a stated commitment from the developer that moving to a safer API will be performed (such as the Printing portal) when it is widely available”.
Sadly it isn’t just using the toolkits (at least for GTK). It depends on which API you’re using for the dialogs. For GTK you need to be using the “Native” named dialog functions to get portal support. I expect those to be the default going forward for new applications, but older ones probably haven’t switched and the API is ever so slightly different.