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

[sivmu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161125/380962ba/attachment.asc>