[arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner]

On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz)
<pelzflorian at pelzflorian.de> wrote:
> Containers are an attempt to solve multiple issues. One is being a
> replacement for bundles. When people sell and distribute a proprietary
> app/game, they presumably want it to run on as many systems as possible
> with as little effort as possible. Having to rely on volunteer
> maintainers is not good, neither is having to maintain a lot themselves.
> Software bundles with all libraries included are the traditional
> solution to this on all operating systems. Flatpak seems like an even
> easier solution.
>
> The real issue in this discussion is security. Traditional GNU/Linux is
> too monolithic. Having more separation between an application and lower
> system layers adds security just like not using root for running a Web
> server and using separate user accounts for e.g. a Web server and an
> XMPP server does. Well-behaved software uses the self sandboxing you are
> talking about: dropping capabilities, revoking privileges. Two issues
> remain:
>
> Presumably most software (online games in particular) do not properly
> self-sandbox and are not secured very well. It’s safest not to install
> such software on your work PC but you may still wish to somewhat protect
> your gaming PC. Despite not knowing the software that well, we can try
> to constrain its privileges via containers/bubblewrap/firejail.
>
> What’s still missing however is proper filesystem isolation. Not every
> program needs to have access to any file in my home directory. More
> separation here is good for security. I don’t want to create a new user
> account for each app. I do want to use something like the new xdg
> desktop portals. I also want to hide what other software I have
> installed. I planned to do something with many small Arch Linux
> filesystems with inheritance through hardlinks, but maybe embracing Guix
> as an additional per-user package manager is a better approach?
>
> The same missing separation may be a reason to use Mach/Hurd over Linux.
> Of course that is still in its infancy.

I'm no fan of the container (docker) craze right now, but I also agree on
the benefits listed above. Further, some applications or suites like KDE
or GNOME can benefit from being bundled, but it's mostly developers
who want to provide a single bundle for all glibc distros that will benefit
in this regard.

The security aspect is real though since I also don't want all network
clients to have access to all of $HOME. How do you know that Dropbox
doesn't secretly copy your ~/proprietary-work-for-boeing folder?
Whitelisting what networked apps have access to in the filesystem is
very important.

Another very useful case would be using containers as a chroot replacement
for having clean (only what's in the recipe), reproducable build environments
for building arch packages. It would also allow installing makedeps only in
the container/chroot or make cross-compilation easier to manage.

Are there plans to support this in makepkg? I believe xbps has this.