On Tue, 2016-01-19 at 11:00 -0500, Colin Walters wrote: > On Fri, Jan 15, 2016, at 06:50 AM, Pavel Odvody wrote: > > Hello, > > > > there's a new release of HICA, system & API for wiring container > > applications back to host based on runtime label introspection. > > This is a cool project, the concepts obviously parallel work done on > modern > application sandboxing. > > However, I would try to separate desktop use cases more from server > side > ones. > > For example: > > - Bind mounts XSocket into the container > > That's currently equivalent to complete control over the desktop. It > always has been with X11. Wayland fixes a lot of the holes, but > it's not on its own a complete solution. The xdg-app people have > been spearheading a lot of things in this area. You're right, for example in the firefox example I had to add '-no -remote' otherwise the container process dies almost instantly and a new tab is opened in my on-host firefox. The abuse of X11 protocol never ends. > > There are some commonalities though with desktop use cases, like > allowing > certain containers access to the GPU. > > And there are more pure server use cases, like allowing a container > access to a portion of a raw block device. (Think databases that > want > to do O_DIRECT). That sounds like great idea for new injector/label pair, I've created a tracking issue for it: https://github.com/shaded-enmity/docker-hica/issues/13 > > I personally don't think the "prompt the user with list of > permissions beforehand" > model really works for mobile/desktop apps. It's a fantastically > hard problem, > but prompting on-demand seems to be more secure. Anyways, I don't > see desktop containers as a focus of this project right now, though > I think a unified architecture is going to be important long term. > In both cases users get muscle memory and implicitly click yes and don't look back. I agree that ad hoc request is better, but sadly Docker/Linux was not designed with that assumption in mind. > For server containers, I could certainly > see if we had a curated and documented whitelist, rather than > prompting, > we have an admin edit a config file to enable permissions for things > like granting databases access to O_DIRECT on selected block devices? > > > The philosophy of HICA is to put the curated whitelist into Labels and rebuild the image - image is reconfigured just by simply changing Labels. Now I realized that Labels should go to the bottom of the Dockerfile, so that the rebuild can be nicely cached. That means that you don't need any external configuration management, just keep your Dockerfiles versioned in Git and rebuild as you see fit. OTOH, I know that there's the Answers file in Nulecule, and I'm particularly torn on which concept is better; I think that the answers file could work nicely in complement with the runtime command line arguments, i.e. instead of doing: $ docker-hica --xsocket-path=/tmp/.X11-unix firefox you could do something like: $ cat answers xsocket-path=/tmp/.X11-unix $ docker-hica -f answers firefox Please open an issue on github if you get some cool ideas like the O_DIRECT; or we can call and figure out some further overlaps with Atomic/Nulecule if you think there's more to discuss - I'd certainly love to see this paradigm getting traction. -- Pavel Odvody <podvody redhat com> Software Engineer - EMEA ENG Developer Experience 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
Attachment:
signature.asc
Description: This is a digitally signed message part