1. 13
  1. 1

    Good write-up!

    Between the vulnerability and the ubiquity of insecure plugs, there seems to be minimal security benefits to Snap applications beside automatic updates.

    For desktop applications, I agree. There are actually a few facets to this issue though, and I would say the least important part is that insecure interfaces (plugs) exist. In an ideal world Ubuntu would be using Wayland, and snaps wouldn’t need to lean so hard on interfaces that provide access to x11. But even then you would still want those legacy interfaces around for distributions that don’t use Wayland.

    Interfaces have a concept of connection: they can be disconnected by the user. Doing so effectively prohibits the snap from utilizing that ability. Another facet to this issue is that a lot of these insecure interfaces are connected by default. If you publish a snap that uses the home and x11 plugs, snapd will happily connect those interfaces on your behalf. You have no way of opting out of that. It means you can publish a malicious CLI-only snap that uses the x11 plug and snoop on everything on the system without the average user even knowing you were using X. This would even happen to power users, because snapd offers no way to disable it. I’ve griped about that in the past and the closest I got was a feature proposal that never got implemented. That doesn’t change the fact that desktop applications won’t be able to function without an interface that grants access to X, but the fact that the user has no voice here is frustrating.

    I like the snap security model. It feels like android, where I can grant and deny permissions based on what they request. But they aren’t designed particularly well. They are so complex that the entire system is hidden from the average user, and even if they WERE as in-your-face as android permissions, it wouldn’t be clear what you were granting in a lot of cases (e.g. what is the difference between network and network-observe as an average user?).

    Definitely room to grow.