[arch-general] On containers. WAS: Re: snapcraft.io ...
This whole sandboxing and containerisation idiocy is such a pain. Oh look, the apps are not secure, the apps sometimes crash. But you know what, let's take a high level approach, because we're such great managers. Let's NOT make better apps and a better stack by actually writing better multimedia libraries. No, let's instead just lock the stuff in which we use anyway, so they can't do more harm than absolutely unavoidable. Let's face it: those wheels are BROKEN, and what we actually need is an effort to reinvent them a few more times so some of them might hold further scrutiny. Slightly off topic, I know, I'll be back at planning my own world domination myself. cheers! mar77i
On 24 Nov 2016, at 15:19, Martin Kühne via arch-general <arch-general@archlinux.org> wrote:
This whole sandboxing and containerisation idiocy is such a pain.
I totally agree. Sandboxing and containerisation is no cure for bad code. When you have a leaking pipe, you shouldn't simply but a bucket below it to keep damage in limits. You should get a better pipe, as the issue will only get worse.
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. --
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 Thu, Nov 24, 2016 at 03:19:49PM +0100, Martin Kühne via arch-general wrote:
This whole sandboxing and containerisation idiocy is such a pain.
Containers are useful — I'm saying this as an admin with 10 years of experience. Having semi-isolated controlled environments for testing, building, just plain not having useless packages pile up on the host is really convenient. Having said that, I think using them to isolate programs is an entirely wrong approach to security. From my experience, making something more complex almost never leads to it being more robust or secure. Another level of abstraction means new bugs — and security holes, of course — which is the complete opposite of what we're trying to solve. What's more, it will harm the ecosystem in general IMO. Even now I see projects abandoning any efforts to make their software packageable — just drop this docker container into your system and you'll be fine! Of course you have to now rely on the upstream to update the container AND it's built on a system that is very different from what you're using in your environment, but who cares, it's a container! So convenient! So safe! I went on a rant there — as I often do — but eh, that's my two cents. P.S. To be fair, this approach isn't limited to containers or snap/flatpak packages. And it's nothing new. Gitlab and Chef are mainly distributed in a single isolated environment that might as well be a container: drop the whole thing into /opt, let it do the rest. Gitlab has its own chef inside FFS. BTW has anyone managed to get the chef server running on an Arch install? I'm seriously asking.
Am 24.11.2016 um 15:19 schrieb Martin Kühne via arch-general:
This whole sandboxing and containerisation idiocy is such a pain. Oh look, the apps are not secure, the apps sometimes crash. But you know what, let's take a high level approach, because we're such great managers. Let's NOT make better apps and a better stack by actually writing better multimedia libraries. No, let's instead just lock the stuff in which we use anyway, so they can't do more harm than absolutely unavoidable. Let's face it: those wheels are BROKEN, and what we actually need is an effort to reinvent them a few more times so some of them might hold further scrutiny.
I agree that using sandboxes as a subsititude for good, trusted and well tested code is wrong. However how confident are you about the security of your own code. Writing complex programs that parse complex file formats like multimedia stuff is very difficult and even with security in mind the result willnever be without bugs. So when used not as a substitube but as an additional security layer, sandboxes can be very useful. As someone said before, e.g. Browser are complex applications with millions of lines of code and they will always have vulnerabilities. Using self sandboxing feature like seccomp and namespaces as done by chromium and firefox, is a very good aproach to increase security and this has prevented many problems in the past. This discussion reminds me of antivirus programs and their effect on user behavior: When used with the mindset that having an antivirus programm will absolutely protect you from harm like often advertised, the effective security will decrease as users will act carelessly. When used as what they are, a seatbelt for the driver/user, it can prevent harm. Unfortunately many users think that with antivirus protection the can "drive" like crazy and crashing into a wall with high speed will not cause any damage since they are wearing seatbelts. However with sandboxes I hope that developers have a better understanding of security and this effect will not be the same.
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. Regards, Florian Pelz
On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz) <pelzflorian@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.
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? -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On Sat, Nov 26, 2016 at 3:23 PM, Bennett Piater <bennett@piater.name> 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 26 November 2016 at 15:08, Carsten Mattner via arch-general < arch-general@archlinux.org> 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/
On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries <maarten@de-vri.es> wrote:
On 26 November 2016 at 15:08, Carsten Mattner via arch-general <arch-general@archlinux.org> 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.
On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries <maarten@de-vri.es>
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.
I only meant reproducible environment but failed to make that clear. This is why I was mentioning a clean env with only what's required to build per recipe and not mistakingly building with stuff that's in /usr.
On 11/24/2016 08:19 AM, Martin Kühne via arch-general wrote:
This whole sandboxing and containerisation idiocy is such a pain. Oh look, the apps are not secure, the apps sometimes crash. But you know what, let's take a high level approach, because we're such great managers. Let's NOT make better apps and a better stack by actually writing better multimedia libraries. No, let's instead just lock the stuff in which we use anyway, so they can't do more harm than absolutely unavoidable. Let's face it: those wheels are BROKEN, and what we actually need is an effort to reinvent them a few more times so some of them might hold further scrutiny.
Slightly off topic, I know, I'll be back at planning my own world domination myself.
cheers! mar77i
Jesus, Marti, I couldn't have said it better myself. While we are at it, why don't we html'ize all the desktops so they look like win10, devoid of any character, just a whole desktop that looks like a bland rendered web-page, devoid of any decoration and with apps that take 1/2 a screen to do what was done in 1/10 the space before (not just plasma), and while we are at that, let's bork the indent and focus models and use a hodge-podge of open, save, save-as dialogs with hit-or-miss kio functionality. I feel better -- thanks Marti :) -- David C. Rankin, J.D.,P.E.
participants (11)
-
Bennett Piater
-
Carsten Mattner
-
David C. Rankin
-
Jack L. Frost
-
Leonid Isaev
-
Lukas Rose
-
Maarten de Vries
-
Martin Kühne
-
pelzflorian (Florian Pelz)
-
SET
-
sivmu