1. 18

  2. 12

    His central point appears to be that Canonical and similar OS vendors want a packaging format with sandboxing so they can have an “App store” without having responsibility for the safety of packages in that store. The sandboxing features of snaps and flatpaks wouldn’t be necessary if users got their packages directly from software vendors because they would “already have a trust relationship” with them.

    Huh? How does that work? I should get my software only directly from producers whom I have an established trust relationship with? This is patent nonsense. Even if we allow that established software producers have an incentive not to do anything naughty in order to not risk damage to their reputation, I might still want to use or try out packages from new companies or individuals in whom I have no such confidence. And even relatively trust-worthy suppliers can make mistakes, have bugs, get hacked, etc. Furthermore, trust-worthiness today is not very stable… there are lots of established actors who will do naughty things if they think they can get away with it, and the bigger they get the more they seem to think they can get away with.

    Bottom line… there is no scenario where sandboxing newly installed software is not of significant benefit to the end user, regardless of whether we get our packages from “App stores” or directly from producers. We do need packaging formats that address that need.

    1. 5

      Bottom line… there is no scenario where sandboxing newly installed software is not of significant benefit to the end user, regardless of whether we get our packages from “App stores” or directly from producers. We do need packaging formats that address that need.

      I am not an expert, but if I understand Flatpak, one could set any privileges one want to the application. They are hidden in the configuration file. So when the average user download a Flatpak, I guess he doesn’t look at the Flatpak configuration file which might give the Flatpak the same privileges as any other “natively” installed application.

      So as a user, you end up “trusting” someone else.

      1. 1

        flatpak install prompts you to accept the transaction before proceeding, which includes the accepting the package’s permissions. Can’t recall what graphical frontends do.

        1. 1

          Can the user add/remove permissions upon installation? (even if this leads to a crippled installation)

          1. 2

            I don’t think so. I believe permissions can be marked optional but if they don’t have that status you can’t get rid of them. That doesn’t change the fact that permissions are visible (I was responding to @Royi suggesting that they’re buried in configuration files).

      2. 4

        We do need packaging formats that address that need.

        What I don’t understand is what a packaging format has to do with sandobxing. The end user needs to sandbox all applications (if she so desires), not only those that the distributor decided so. A hostile distributor may force a leaky sandboxing for his application, defeating the whole purpose of sandboxing.

        1. 1

          If your distributor is hostile, you are already lost.

          1. 1

            Not at all if you OS supports sandboxing of applications.

            Besides, being “hostile” is in the eye of the user. For me, auto-updates are an extremely hostile behavior and financially onerous (cf. expensive connection via a phone tether). Thus, snaps are hostile by definition, yet I cannot “sandbox” the auto-update thing.

      3. 8

        I think that coco and others who mentioned it are certainly correct that the package format, by itself, doesn’t improve the security situation. We need better support in Unix distributions for sandboxing of end-user applications. These package formats do help with that, in that by bundling all the dependencies inside the package, you relieve the distribution from the burden of identifying the dependencies and copying them in. Of course, to do it properly you would want the distribution to enforce the details of the sandbox configuration, rather than relying on the package to do it.

        As with containers for server software, this approach has drawbacks. If the distribution isn’t providing the dependencies, it also doesn’t have visibility into whether they’re up-to-date with all security patches. So these package formats as they stand actually take control away from end users… I can’t say I’m a fan. In other words, distributions should want to be involved in identifying the dependencies and copying them into any sandbox that’s being used.

        I do understand the benefit to having a format that works across distributions, but I really think that benefit is almost entirely to software publishers, and not to end users or to distribution maintainers. At least in the server world, system administrators do get some benefits from containers, but I don’t think that applies here.

        Since I do have higher-than-average security needs, I actually don’t ever use Flatpak, since the security trade-off would be unacceptable to me. I regard it as an important security feature to have binaries that are built by my distribution’s tooling, not by the software publisher. That means there are apps I can’t use at all, but that’s just how it is sometimes.

        I will take the opportunity, in passing, to plug NixOS. There is more work to be done wrt sandboxing of graphical apps, but you can already write a Nix package config which will build a Flatpak binary based on a Nix config, rather than on an upstream, publisher-provided recipe. Nix is far better than any other system that exists today, as far as easy configuration of dependencies. I hope that as people think about better solutions to these problems, they’ll keep the Nix tooling in mind and build on top of it when it makes sense to.

        1. 1

          I agree with the view that the first level benefits are primarily to software creators. Software creators get to build one artifact that will work on all Linuxes, and they get to distribute that artifact through a single place (where users can discover it, at least theoretically) instead of many. People like Canonical benefit indirectly through more software being available for Linux and perhaps through running the Snap store which leads to getting to take a cut of any purchases through it. People using Linux theoretically benefit through more software being available for it (and for their distribution), while small Linux distributions might benefit through more software being usable on them.

          (I’m the author of the linked to article.)

          1. 2

            I mean, this trend is specifically taking resources away from efforts to support packaging software properly for distributions. Users who understand their security needs have less software available as a result of it.

        2. 1

          Canonical will have seen how much resources Apple and Google put into auditing submitted apps, in environments with much better fundamental security than standard Linux has, and they almost certainly want none of that.

          Apples and Googles App Store is quite profitable afaik. That is probably what Canonical wants.