You can't run unsafe software in safety, it's a myth. Or worse is giving trust to a specific tech and so ignore both it's potential mistrust and other software security implications.
The future for me is Nix{,OS}/Guix{,SD} certainly not "chroots"/"jails"/"zones"/"lpar"/*.
They can be used also for development create isolated FHS environments with a simple text file describe the environment, again without containers.
That's one of the reason I consider them the future, you have:
- built-in infrastructure as code
- built-in immutable servers
- built-in orchestration/provisioning
All with human-readable, easy to manage, text files.
> In my understanding the main incentive for the huge push behind them was immutability and them being microservices-friendly technology.
I'm not a container historian, but I believe this came later: when Docker and the like entered the scene with their ideas of immutability, LXC on Linux was already several years old, and BSD Jails / Solaris Zones probably a decade older still; and they were all quite mutable.
When I first came across them, I viewed them as very lightweight VMs, with (as you say) rather insufficient security, but still useful for experiments or to segregate services for ease of management.
To be honest I think it unfair to ignore the fact that you can build your own containers to leverage dependency isolation, or to deploy through an orchestration engine ie. Kubernetes.
Today's mania of "data", most of the time meaningless (they "prove" different and often opposite things depending on how you arrange them) it's a way to silence discussion or prove true false things.
Consider a simple thing: traditional FOSS model consists of:
- upstream devs that release their code
- many independent packagers of various distro check out that code and package it
- users get packaged code by their distro
This means that many eyes see the code at minimum enough to compile and figure out why it doesn't work properly in their distro. They often patch and suggest improvements. Users get different binaries on different distros. Due to actual package model proprietary software can't be easily distributed as first class citizen by the vendor to the users simply because package an apps for any distro is unfeasible. Proprietary vendor have two options: allow redistribution so distro packagers (many different subjects) control distribution of their binaries or support only few distro leaving the over aside.
So in synthesis in this model proprietary software is not first class nor welcomed and many different subjects with many different idea, environments etc pass the code around make it more portable (or it's a pain to be ported), up to date (or it's a pain to compile on different distro since [br]deps aren't under upstream control and no unique binary is around to be tried to exploit thanks to various bugs.
In "container model" especially snap&c upstream package the final binary with all dependency. No more single independent distro packagers have to exists. No more need to be up to date for the upstream due to [br]deps updates on various distro. No more packagers check and improvement suggestions/patches from packager to the upstream. Only a straight line from "producer" to "consumers". Ideal situation for proprietary software since it can be now first class. Distro reduced to be a platform like a cargo ship instead of a compilation of various software, i.e. having different distros became meaningless since they are only a base for application.
That's is. On FOSS/traditional model collaboration of different subjects with different interests, idea, competence, scattered around the world is NEEDED by design. On container model no communication is need and there are "compartments" between "producer" and "consumers" instead of an heterogeneous blends between them.
Any time you reduce diversity, you compartmentalize, you empower people letting them operate "alone" you get bed results. That's the best "data" to back up such assertion. Is freedom and collaboration vs isolation in a rigid, compartmentalized system.
To have a big "security proof" take a look at how many vulnerabilities and how serious they are in proprietary products vs FOSS software.
Most container implementations were not born with security in mind. Also, overlay filesystem are not required for improving application isolation.
There's a zoo of unmaintained docker images, snap and appimage packages & same Linux distributions that are full of vulnerabilities.
Nobody care or has the time to backport security fixes to whole zoo, unlike traditional distributions where maintainers are responsible for doing that.
Statically compiled languages are only making things worse.
This is going to come back and hurt all of us in few years.
Anyway for me OS partition or real virtualization are similar beast, while on power they have no overhead they are still a sign of bad development model. A way of avoid solving a problem proposing "intermediate" solutions.
I agree. Especially Flatpak and AppImage facilitate this goal.
I do run some software that communicates with the internet in a bubblewrap sandbox, like Chromium and Transmission, but other than that I shouldn't have to run every piece of software in a container to be safe.
That's easy for companies since they deal with "standard" "Ford model like" people, but that's a killer for evolution especially evolution driven by people/users, not upstream/companies.
If you can tailor software to fit your needs as you like you get a friendly personal environment and you have "a bit of power" on society, you still need upstream work but you are also a bit independent, and the same is for upstream to have help from the community they need to comply with an heterogeneous community with users, not consumers. We are in the end interdependent so forced to cooperate in a relative peace. On the over side we totally depend on upstream being effectively powerless. Oh yeah, you can choose different software, at least for now, but that need to exists, that's no more a community.
A simple example a proprietary software, Master pdf editor, gain a bit of success in GNU/Linux world and decide to insert watermark on modify pdfs by free version. If it's distributed by single distro, single distros can keep old version for long time. Leaving all needed time to their user to switch. If you relay direct on upstream you discover the new "feature" a day perhaps without warning because it's auto-updated for instance, and you may have no time, no choice. This also happen recently with the "tweaked" Android settings by Google and I think many many other cases.
Freedom it's not only "being free of doing something" it's also can do something easily, have a system that let you be as free as you like.
For security you'll need some other mechanism, but it does solve the immutability / replication problem.
I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done.
On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version.
With containers, you have to rely on each and every container to update libsodium...
Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage?
Very interesting either way, and got me thinking about using such for specific cases.
The pledge/unveil model is far more elegant.
> What does it do to memory usage, and disk usage?
You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient.
But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
see the links I posted above, if every package (or a subset of packages based on the underlying source package) in a traditional linux distribution is treated as an independent layer that can be composed together on demand (i.e. what happens when you install a package, except much slower) using a traditional union file system you get deduplication (as every image using that package will be sharing the same exact portion of the file systme) and you get memory sharing for free (for exact same reason, as its fundamentally no different than multiple processes on a single host dynamically linking the same binaries).
Until all your packages decide to use different versions of their dependencies.
I'd argue that docker copied this in a degenerate way, but that those papers implemented what you asked for.
The main source of trouble is web browsers and IDEs having problems at low memory... (As if 2GB is not enough RAM for a web browser or a glorified text editor. Shame on them!) Those same applications cause trouble on 8GB system.
Of course you will need more if you want to play high end games in a VM. Or run many Windows instances as that hog eats 512 MB RAM when fully loaded in and doing nothing. (Unless it is ReactOS which is still frugal.)
16 GB RAM essentially guarantees high comfort in a such VM system as you can usually allocate extra GBs to offending special purpose VMs.
It seems that that could be a nice thing to have with basically any kind of software package on the desktop as well. In a way that is the attraction of having browser based software: you just go to a particular website to run a web app. No installation needed. No need to worry about updates. Just run it.
I actually get the architectural purity that drove this person to do this. Why settle for less? Why accept all the kludges, legacy cruft, stupid hacks, and ugliness that we accept as normal? As, she's demonstrated, there's no good reason.
An important aspect of it, I think, is "rootless" podman -- I can create and manage containers without elevated privileges. Any required root escalation is done in the containers.
Still, it is weird. GUI apps do work, but hmm.
Solaris Zones are better-integrated than this newfangled podman stuff that you kids are using these days.
That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.
I'd love to see what you propose, but I don't think there is anything remotely similar.
To be clear: I have no real reason to do this, other than to just see how it works. It’s nice to know that if I got a new machine tomorrow, all of the CLI stuff I need is defined in some Dockerfiles and bash aliases, and could be reinstalled pretty quickly. There are other ways to do that, but it’s a fun experiment. In practice, there’s really very little noticeable overhead to running things this way on modern hardware, but I’m also not running things in tight loops where that overhead would matter.
If you’re curious at all about this, Jess has a couple of Github repos worth looking at:
https://github.com/jessfraz/dockerfiles/
https://github.com/jessfraz/dotfiles
Specifically, her aliases are set up here: https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc
Thanks
But I can't think of a valid reason why anyone would want to use this in practice when there is QubesOS. If the reason is to increase my base-layer of security for OpSec, then this is a poor choice. Perhaps this is what she meant in the slides when she says don't try this at home ... maybe she explained it better in the talk (I haven't watched it). Seriously don't do this at home unless it's for educational purposes (in that case I agree it is awesome).
