Subuser turns Docker containers into normal Linux programs, limiting privileges
subuser.org
subuser.org
My favorite part of reading the docs for subuser is how completely direct and honest they are about security of various features. E.g., if you enable some features of X bridging, you're accepting security risks, because that's how X works. (And if you don't need those features, don't enable them; it looks like subuser has it down to a one-word config flag, which is amazing.) By comparison, if you start out on your own... there's lots of brief tutorials on the internet about using xephyr, or xpra, or doing something really wildly unsafe like just plain mounting the X sockets in. But not only are all these things rough to get started on by yourself, the brief explanations thrown around are often not clear on the security implications. Subuser seems like a great way to do the right things... out of the box. And with excellent truth in packaging.
I've accumulated a lot of scripts in my personal `~/bin` over the last couple years that do stuff like "mount cwd and interesting dir $x, make sure image with $prog is here or fetch it, now pass args and invoke $prog with $HOME=..." -- and while these have been really useful to me, they've been ad-hoc and almost impossible to usefully share with others. Subuser's format for making valuable configuration like this sharable is extremely interesting.
So, good to see a project look at that aspect. I would quite like to be able to run all my apps which access untrusted services (e.g. all browsers) in a container which I can easily wipe/reset.
I wonder how it compares with zeroinstall or nix
I don't like that.
As this is opensource and I get the source, I will download a full OS image or containerized binaries from third parties. Mmmm so spectacular.
Apps running on chroots? We've that since the 90's, the relaxed security model of Xorg and it's client/server architecture was there already, and it was the reason to left windows 3.11/95 behind.
But marketing campaigns are spectacular in effect in current money surrounded culture. Yes. Their network effect is spectacular. I would say so.
Edited: missing question mark
In the future, I would like to expand on the vision, to include the ability to do deduplication, so that all those zip files with bundled dependencies take up less space. And deduplication done right, will save bandwidth too. Indeed, when you have these "deduplicated zip files", with deduplication done algorithmically, you'll save even MORE space and MORE bandwidth than with a traditional dependency resolving file manager. Take for example debian. Debian uses packages. These packages have dependencies. The dependencies are shared. This saves space over a case where you have a bunch of zip files with unshared dependencies. But when you update a dependency, even if only one line of one file has changed, that dependency must be downloaded completely anew. But with algorithmic de-duplication, updating one line of one file means you only have to download one line of one file anew.
Space savings are there for a similar reason.
I would really recommend you look at nix, zeroinstall, click packages and http://0pointer.net/blog/revisiting-how-we-put-together-linu...
There are people out there who would love to financially support this if you ask and have a good sense of what you want to do. IMHO your post above (about zeroinstall and click) are jumping the gun.
Would love to see what you come up with.. once the excitement has died down ;)
I'm just waiting for some project to be wholly dependent on the existence of networkd or some such...
Fortunately still I'm free to use my non market targeted, written by myself, configuration management tool, to pick how i boot my personal systems.
Sorry, will not buy more blog posts from that domain.
But... Won't it be an ugly kludge?
From what I understood, Subuser does introduce the duplication problem just because of the way it works. It didn't exist with traditional package management when done right (because shared components are packaged separately), and it didn't exist with Docker (because it uses layers). If software (any software) essentially adds some issue and then tries to fight it off, it's very likely that things will be ugly in architectural sense.
> But when you update a dependency, even if only one line of one file has changed, that dependency must be downloaded completely anew
Are you aware about debdelta?
There's a big spectrum of 'solving the deduplication problem' and Docker is towards the 'when all you have is a sledgehammer' end.
Saying "you can manually arrange Dockerfiles so that they cooperate and share layers" is not solving things in an architectual sense! You essentially have to be using a single custom tool (Dockerfiles) to create your images and then you need to apply thinking power to consider how best to arrange your images (e.g. having a 'base' package.json to install a bunch of things common to many apps, then additional an additional package.json per-app).
It's getting better with 1.10 (layer content is no longer linked to parent layers, so ADDing the same file in different places should reuse the same layer) but it's still pretty imperfect. I created https://github.com/aidanhs/dayer to demonstrate the ability to extract common files from a set of images and use it as a base layer, which is another improvement. Even better would be a pool of data split with a rolling checksum, like the one bup creates - short of domain-specific improvements (e.g. LTO when compiling C), I think this is probably the best architectural thing you can do.
Data compression (which deduplication essentially is a subset of) absolutely isn't a kludge. I meant, introducing the duplication (by design) and then inventing some workaround to get back to square one - that's the suspicious part. It adds complexity, when there could be none.
Isn't it Subuser that crams all the dependencies together, in one place (image)? So there was that proposal so images are deduplicated, in a sense shared files are automatically detected and stored only once, saving disk space. But then, isn't it that Subuser is completely unaware of any metadata a particular file may have, so it can't really tell the difference between libz and libm, or know that all those binary-different libpng16.so have the 100% compatible ABI and are interchangeable (but not all libpng12.so do)?
From what I understood, Subuser is a package manager (plus permission manager) that doesn't know a thing about what it's packaging - only the large-scale image.
Package managers have all libraries separate, that's the whole point why package managers were invented in the first place. If a package management uses some database, dependencies may lay together in the filesystem, but the're completely separate in package manager's database. If package management system uses filesystem as its database, then packages are separate in that regard, too. There's immutability as well, sometimes enforced, sometimes along the lines of storing `dpkg -l | grep '^ii' | awk '{ print $2 "=" $3 }'` output to save the exact state.
People is calling "containers" to operative system images pulled from third party repositories under certain laws.
If we left all that behind, yes, it's better if your firefox cannot read you ssh private key for example. But I don't need docker for that, sorry.
I need a third party blob, when I don't want to embrace the postgresql source code for free and it's manual, and make myself more free tomorrow.
But the... how many millions was it? dollars campaign behind certain technologies (and providers), has more power than any thinking, regarding network effects.
I can understand.
Money surrounded culture does not exclude those that don't have the money, they are simply part of the game.
This doesn't solve any problem I have currently or I cannot solve using tools I've already tested on my usage, but I hope you had fun writing the software and sharing it.
The other thing that is good about subuser is the isolation that it provides. If you download some new freecad plugin from some random person, and that person made a mistake and their plugin damages your system, then that sucks. But subuser can help contain that damage. It also has some protection agains malicious software. Short of a kernel bug, it's pretty hard to break out of subuser's containers. So if you EVER download development versions of software that are from non-vetted sources, you should consider installing and running that software through subuser. It will make you safer, and if enough people do it, and make subuser images, then it'll also save everyone in the free software world a lot of time :)
I did look better to your software, even if I avoid docker, and it looks nicely engineered and documented.
Congrats. Really. Thanks for your effort and for sharing it.
To don't just another comment, regarding the apt-get stuff of other comments: I build my packages and repos the same, since the 90's... but I was not an early docker adopter, because I was unable to run private registries. I cannot compare them sorry :-)
Have a nice day, and sorry for hijacking your nice project with my docker rage.
Will the golden age of a single package manager across distro be finally possible through Docker?
What I would like to have in the future, that Docker does not provide, is deduplication. If I have two images with the same file in both, then I should be able to have that take up no more space than if there was one file in one place. See https://www.youtube.com/watch?v=2Sc6_XgNXyk
docker pull postgres
and get a postgres service which runs in a container.
the commands needed are right there on the docker hub page
https://www.cl.cam.ac.uk/research/security/capsicum/
Docker docker docker docker
Your approach has the problem of needing the inherent insecurities of docker. Because everything within docker has to be managed either by root or someone within the docker group, you have a greater surface area exposed where if an malicious app is able to get hold of the docker socket file, it now owns your system. A capability-based security system, on the other hand, wouldn't be able to touch the docker socket, even if it was run as root.
But context changes and needs have become more sophisticated, particularly needs in isolation, consistency, elasticity. I think that the capabilities of traditional Unix kernel mechanisms, packaging systems, and userland tools, have lagged behind demand.
There's still opportunity for these needs to be met with refinements to standard 'nix mechanisms. I'd contribute to such a project, if it became the explicit design direction of a major distro.
The answer to your question is that it all depends on your definition of "easier".
docker/docker hub hide a lot of complexity in linux namespacing/cgroups/seccomp filtering. You can absolutely achieve the same goal with native linux tools, as long as you have the time and inclination to learn those tools.
So I guess I don't get any millions. :(
http://adamierymenko.com/docker-not-even-a-linker/
If everything (mysql, pgsql, etc.) were a library you could achieve much of what it does with -static and privilege dropping on launch.
Zeroinstall is distribution centered. It allows you to easilly distribute software across distros.
Subuser is like zeroinstall + firejail.
The daemon runs as root, so your containers are only as secure as the daemon itself.
> The daemon runs as root, so your containers are only as secure as the daemon itself.
This is not correct. The daemon only starts and monitors processes in this case. You can start a process as a different user. You can also use user namespaces to make "root in the container" not root on the host.
This did not automatically lead to allow a contained user to breakout, but made it easier.
In 1.10 user namespacing reduces this risk as the root user in a container can be remapped to another user account outside the container.
I understand this is solely for Linux programs?
It seems like it would make sense to combine this with subuser to make sure you keep a known-good version of wine and its configuration. I've known wine compatibility to drift unpleasantly from time to time, or accidentally lost obscure config changes I made once...
(I have fond memories of a time when I could play Supreme Commander on linux in wine... but I've since lost that machine, and I haven't been able to reproduce the dang setup again since :( If subuser had existed back then, I'd probably have a snapshot and I'd be happily playing right now...)
Probably not. Technically, wine was able to run various versions of Photoshop for years. But it was never stable nor complete enough to use it professionally, with wacom tablets and such.
Warning: Being a member of the docker group is equivalent to having root access.
Not a great way to limit privileges.
For a single-user machine, it may be okay. But I don't trust Docker's security very much.
I suppose most of them will be needed in this case, and it's still a concern.
Just did want to remember to people about linux capabilities after read your comment:
man -k cap | grep capabilities