[gentleman11]

Devils advocate: it is plain weird for every app I install to have so much file system and system access. It’s nice to have a sandboxed solution built in. It would be nice if it was a solution that didn’t have the problems that this article listed, but snaps could be adapted to be good with a few changes.

Why a proprietary backend though? I suppose cannonical views packaged apps as a platform opportunity and wants to be the first to “capture” the users without somebody bigger coming and taking over?

[2ion]

> Devils advocate: it is plain weird for every app I install to have so much file system and system access. It’s nice to have a sandboxed solution built in. It would be nice if it was a solution that didn’t have the problems that this article listed, but snaps could be adapted to be good with a few changes.

Exactly. Personally I have been sticking my desktop programs into "firejail"-managed "containers" for a long time. It's a good thing that a similar solution has been implemented that is suitable to bring this too the masses.

[yjftsjthsd-h]

> It's a good thing that a similar solution has been implemented that is suitable to bring this too the masses.

Couldn't you just make a "default-firejail" package that installs the symlinks to firejail somewhere that's before the default install install location in your path? And maybe consider installing that in the base install, but that potentially risks breaking things unexpectedly for users.

[lucb1e]

Wasn't AppArmor already doing this though? If I remember correctly (and I never properly read up on it, so please correct me if I'm wrong) it limits which syscalls you can do and with which parameters, like opening only certain files. I think apparmor rules/profiles were becoming more common to be delivered with their respective packages (I'm using Debian), and it sounds like that already solves your exact concern without deviating from apt:

> it is plain weird for every app I install to have so much file system and system access

A quick glance at Wikipedia to make sure I'm not talking out of my ass seems to confirm that:

> is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths. [...] AppArmor is enabled by default in Debian 10 (Buster) [from July 2019].

(Also, I'm not a fan of claiming "devil's advocate" when you're saying something that you know everyone will agree with. It's similar to saying "downvote me all you want but [insert popular HN opinion]". Of course the principle of lease privilege for software is something lauded by every logically thinking person.)

[war1025]

AppArmor has only ever caused me pain.

For whatever reason it's decided that I'm not allowed to connect to the network.

It's easy enough to remove the package, but it likes to tag along as a dependency when installing updates.

[lucb1e]

Sounds like snaps are causing more pain than apparmor though?

I mean, if you want security but don't want the inconvenience that comes with new efforts towards sandboxing, then either you have to read up and help in the effort xor wait for others to fix it and run old and stable software xor not have security.