4 ms·

I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted. > You install it, at w

I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted. > You install it, at worst it will cryptomine that is it. If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing. > Oh and you can remove it completely with all traces unlike deb equivalents. Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed. In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.

kd913 6y ago
>If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing. You can be rest assured that the problematic snaps were tackled and addressed within 3 days, there are no cryptominers on the store anymore. That and it was actively searched for. Why are you downloading random crap from teh snap store to begin with? People always take extreme perspectives over this and I find it weird. No you probably shouldn't be installing hello-world snap from Davind1923232. I wouldn't expect you to do that on Android or any other manufacturer. It probably is safe, in that it has had as much vetting as any other store owner. Downloading firefox, vscode, intellij, vlc, nodejs, spotify and all of these other first party snaps is perfectly fine. >Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed. Snap permissions aren't controlled just by the author. I have disconnected plenty of plugs that don't magically reappear. Especially for sandboxing internet facing programs from my home directory. Snaps can't magically persist that is a load of FUD. The files needed are stored on squashfs, home config and configuration in it's own isolated directory. On removal, the squashfs is removed and that is gone. >In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM. Why do you comment on things you really don't seem to understand. This is the entire point of snap plugs/connections which are enforced permissions based model.
- jamieweb 6y ago
  > Why are you downloading random crap from teh snap store to begin with? I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally. As long as I only use the default repositories, I can `apt install` a package I've never even heard of and it's pretty much guaranteed to not be malicious/actively dangerous. With Snap, this guarantee doesn't exist to the same level. Sure, there is moderation and review in place, but this puts the Snap Store in the same realm as other stores and 'community maintained' package managers, almost all of which have issues with junk/dangerous packages. > Snaps can't magically persist that is a load of FUD. Yes, in many cases this is right, but some of the most common Snap interfaces (multiple of which can auto-connect) would provide enough leverage on a system to gain persistence or actively interact with things outside of the sandbox. For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.) The `x11` interface can even be auto-connected, and this potentially allows the Snap to read the graphical output of other applications. I agree that these scenarios are quite theoretical, but as foresto says in this thread, 'sandbox' implies 'safe', and sandboxed Snaps are quite leaky compared to other sandboxes such as Firejail or a full-blown VM. Perhaps this is just a terminology problem? I would say that Snap sandboxing is far more comparable to permission management on an Android phone.
  - kd913 6y ago
    >I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally. If you are that concerned about typing the wrong thing then use a software center. I have never even seen one and I have been using snaps since their inception. I am using 38 snaps and I have never once installed something i didn't intend to do. I also tend not to run sudo commands without knowing what i am doing. It's not like launchpad, or universe isn't full of junk software too. I think you can download an open source rootkit via apt as if that matters. > For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.) You can't gain 'persistence' just from the home interface. In fact the only way of getting 'persistence' AFAIK, is through creating a systemd snap like ufw. Again, I am fairly certain that stuff requires manual vetting before being published to teh snap store. X11 vulnerability applies to everything, and will apply to everything until wayland is usable. Connecting it automatically means that users actually have a functioning browser. That is a sane policy because users shouldn't have to mess with configuration files to get their programs to work (unlike firejail profiles). All you are describing are permissions which are generally needed to actually run useful programs. Yes, programs automatically connect them. I do suggest reviewing software permissions before executing it, and you can do that with snap. >sandboxes such as Firejail You are talking about leakyness and mention Firejail? Firejail has historically had the most severe CVE vulnerabilities partly because of how usernamespaces/network namespaces work. It was basically a setuid binary and proved a easy mechanism to get root. Snap is built using the same tech as namespaces, but doesn't act as a setuid binary (I think because it uses mounted namespaces rather than creating a usernamespace). It uses the same seccompf, and same browser sandboxing. The bonus of snap is that it actually comes with working apparmor profiles unlike firejail.

kd913 6y ago

>If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing. You can be rest assured that the problematic snaps were tackled and addressed within 3 days, there are no cryptominers on the store anymore. That and it was actively searched for. Why are you downloading random crap from teh snap store to begin with? People always take extreme perspectives over this and I find it weird. No you probably shouldn't be installing hello-world snap from Davind1923232. I wouldn't expect you to do that on Android or any other manufacturer. It probably is safe, in that it has had as much vetting as any other store owner. Downloading firefox, vscode, intellij, vlc, nodejs, spotify and all of these other first party snaps is perfectly fine. >Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed. Snap permissions aren't controlled just by the author. I have disconnected plenty of plugs that don't magically reappear. Especially for sandboxing internet facing programs from my home directory. Snaps can't magically persist that is a load of FUD. The files needed are stored on squashfs, home config and configuration in it's own isolated directory. On removal, the squashfs is removed and that is gone. >In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM. Why do you comment on things you really don't seem to understand. This is the entire point of snap plugs/connections which are enforced permissions based model.

jamieweb 6y ago
> Why are you downloading random crap from teh snap store to begin with? I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally. As long as I only use the default repositories, I can `apt install` a package I've never even heard of and it's pretty much guaranteed to not be malicious/actively dangerous. With Snap, this guarantee doesn't exist to the same level. Sure, there is moderation and review in place, but this puts the Snap Store in the same realm as other stores and 'community maintained' package managers, almost all of which have issues with junk/dangerous packages. > Snaps can't magically persist that is a load of FUD. Yes, in many cases this is right, but some of the most common Snap interfaces (multiple of which can auto-connect) would provide enough leverage on a system to gain persistence or actively interact with things outside of the sandbox. For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.) The `x11` interface can even be auto-connected, and this potentially allows the Snap to read the graphical output of other applications. I agree that these scenarios are quite theoretical, but as foresto says in this thread, 'sandbox' implies 'safe', and sandboxed Snaps are quite leaky compared to other sandboxes such as Firejail or a full-blown VM. Perhaps this is just a terminology problem? I would say that Snap sandboxing is far more comparable to permission management on an Android phone.
- kd913 6y ago
  >I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally. If you are that concerned about typing the wrong thing then use a software center. I have never even seen one and I have been using snaps since their inception. I am using 38 snaps and I have never once installed something i didn't intend to do. I also tend not to run sudo commands without knowing what i am doing. It's not like launchpad, or universe isn't full of junk software too. I think you can download an open source rootkit via apt as if that matters. > For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.) You can't gain 'persistence' just from the home interface. In fact the only way of getting 'persistence' AFAIK, is through creating a systemd snap like ufw. Again, I am fairly certain that stuff requires manual vetting before being published to teh snap store. X11 vulnerability applies to everything, and will apply to everything until wayland is usable. Connecting it automatically means that users actually have a functioning browser. That is a sane policy because users shouldn't have to mess with configuration files to get their programs to work (unlike firejail profiles). All you are describing are permissions which are generally needed to actually run useful programs. Yes, programs automatically connect them. I do suggest reviewing software permissions before executing it, and you can do that with snap. >sandboxes such as Firejail You are talking about leakyness and mention Firejail? Firejail has historically had the most severe CVE vulnerabilities partly because of how usernamespaces/network namespaces work. It was basically a setuid binary and proved a easy mechanism to get root. Snap is built using the same tech as namespaces, but doesn't act as a setuid binary (I think because it uses mounted namespaces rather than creating a usernamespace). It uses the same seccompf, and same browser sandboxing. The bonus of snap is that it actually comes with working apparmor profiles unlike firejail.