On Thu, Nov 24, 2016 at 08:41:12PM +0100, SET wrote:

...

This whole sandboxing and containerisation idiocy is such a pain.

This topic has gone generic, so here are my 2 cents : those who don 't trust an app should just avoid it, and not even look at it; no one is bound to use an app; don 't contain, use something else.

Sometimes you don't have a choice. Any modern web browser comes to mind... Cheers, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz) 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.

On Sat, Nov 26, 2016 at 3:23 PM, Bennett Piater wrote:

...

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.

Out of curiosity, what's wrong with makechrootpkg?

Thanks I wasn't aware of it.

On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries wrote:

On 26 November 2016 at 15:08, Carsten Mattner via arch-general wrote:

...

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.

To my knowledge, makechrootpkg uses systemd-nspawn, which means it is already using a container. Reproducible builds will need quite a bit more work than simply using containers though.

And since this whole thread is widely off topic already, there is a totally different approach to isolating untrusted apps: cloudabi [1]. Instead of making isolated traditional posix environments to run untrusted applications, cloudabi makes it impossible to access global resources such as the filesystem and network by providing only a subset of system calls. For example, there is no `open()` syscall, but there is `open_at()`. Resources can be given to the process by leaving open file descriptors when it is exec'd, or by sending file descriptors to it over a unix socket.

The biggest drawback is of course that existing software can't simply run under cloudabi because there are syscalls and libc functions missing. Also, controlling access to network resources is troublesome, but I like the general idea: instead of adding complexity of multiple isolated environments, cloudabi removes complexity by stripping system calls that can access global resources. There is a working patchset for the Linux kernel already, though not upstreamed yet. See [1] if you're interested.

[1] https://nuxi.nl/

I know CloudABI from FreeBSD, where it's integrated like Capsicum and netmap have been for a long time. It's unfortunate Linux suffers from NIH in this context.