Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker containers on the desktop

blog.jessfraz.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Docker containers on the desktop

#51

Post by SEJeff »

alexlarsson wrote: post #20
habitue wrote: post #11

In a recent article on sandboxing in linux [1] it was mentioned that "X11 is impossible to secure". I'm not sure how deep that goes, or whether it's relevant to what's been done here. Could someone more knowledgeable comment? [1]: http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe...

Basically, all the clients that connect to an Xserver has full trust in each other. You can sniff on any event sent to any client, and send fake events (that are not detectable as fake) to any client, as well as read all the contents of any windows. This essentially means any client can do whatever the user can do. People have tried to make it more secure in various ways (trusted X, selinux X), but it is impossible b…

Wayland will eventually fix/mitigate this, correct?

Re: Docker containers on the desktop

#52

Post by zenlikethat »

mrfusion wrote: post #46

Would this be a good way to deploy an opencv based solution? I spent an entire day getting opencv with Python bindings installed on my Mac and I'm dreading deploying it anywhere else.

Not sure if there are graphical interfaces pieces to your application that need to be considered, but in general Docker is very helpful for problems like that ("I set this up once and god help me if I can ever set up the dependencies and configure my system the same way again").

Re: Docker containers on the desktop

#53

Post by geofft »

teraflop wrote: post #36
alexlarsson wrote: post #10

This is not sandboxing. Quite the opposite, this gives the apps root access: First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you un…

AFAIK, breaking out of a Docker container isn't as trivial as the first part of your comment suggests. In particular, a Docker container can't run other Docker commands unless you grant it access with something like "docker run -v /var/run/docker.sock:/var/run/docker.sock". Of course, there have been other vulnerabilities in the past allowing containers to get root. And the X11 weakness alone is enough to not treat t…

I'm not entirely sure what Alex meant there, but I think his comment there was that the only way to be able to make use of this (at least until user namespace support lands in Docker) is for the user to have effective root on the system. So even if the sandboxing works, it's being done at a cost of requiring that, outside the sandbox, the users have an easy and passwordless way to gain root. This not only gives apps way more power than they had in the event of a sandbox escape mechanism (like the X11 socket), it also gives every unsandboxed app on the system way more power.

It's kind of like the general distaste for setuid binaries. If you have a correctly-written setuid binary, then you can use it to sandbox a process by, say, running it in a chroot. But if it's not correctly written, you have problems on your hands that far outweigh the problem you were originally trying to solve. So a random desktop app that ships with a setuid helper binary is going to be seen with suspicion. (Chrome is the only one I can think of that ships one, but they probably employ the people most qualified to write a bug-free setuid app, and they're getting rid of it in favor of user namespaces anyway.)

Of course, for the average developer desktop, processes probably have fifteen ways to gain passwordless root anyway. I certainly set sudo to nopasswd for convenience. :) So on a developer desktop, it's a nifty hack, although it doesn't gain you security against a malicious app/exploit. But as a general-purpose sandboxing approach, it's a bad tradeoff to make.

Re: Docker containers on the desktop

#54

Post by rdtsc »

jessfraz wrote: post #19
alexlarsson wrote: post #17

Earlier quoted context omitted.

Not sure what you mean, any user with access to docker can run processes as root, with any part of the host system mounted into the container. Now, that access was not added by you, but its required to be able to run your images. Once you have the images running the code in them could easily break out of the container via X11, and do things like sniff all keyboard events and inject events into any app. Of course, the…

yes but you are kinda ruining the point, this is a fun hack with Docker, take it or leave it, that's all.

"Take it or leave it" is cool if it is a game or "I like the font to be blue" or "you are using Haskell, why don't you use Javascript instead". They should totally leave it and move on.

But now. He mentioned a valid security issue and instead of being glad and acknoweledging it you are dismissing it. With security issues that is not cool.

It doesn't help probably that you put "Docker" or "microservices" in the headline it would get upvoted to the top.

Re: Docker containers on the desktop

#55

Post by geofft »

jeswin wrote: post #50
geofft wrote: post #28

This is neat. But. Docker isn't sandboxing in a security sense. It's sandboxing in a deployment sense: given a friendly app and a friendly host, the app can get an environment it wants without bothering the host to adapt too much. Given two friendly apps and a friendly host, the two apps can see different environments. Given an unfriendly app, Docker is no different from running the unfriendly app directly. I think t…

> Given an unfriendly app, Docker is no different from running the unfriendly app directly. I understand the risk of a kernel zero-day. But for Desktop apps, when used in conjunction with SELinux, can't Docker be considered to provide a level of sandboxing? In fact, I have not heard of any container breakouts. AFAIK, the only incidence that came close (but only worked on unpatched Docker) was https://news.ycombinator…

Without user namespaces (CLONE_NEWUSER), which Docker currently doesn't use, uid 0 inside a container is the same thing as uid 0 outside it. If you let Docker run apps as root, which seems to be not uncommon, then it is, in a strong sense, the same as the root user outside the container. That's why Jessie's gparted process can partition her disk: as long as it can get at the device node, it has full permissions on it.

Apart from things that you've explicitly given it access to (like device nodes), the risk of zero-days is higher because these sorts of things aren't quite zero-days: it's not fundamentally a violation of the kernel's security model for uid 0 to be able to do root-y things. You might want it to be unable to, and you might mostly succeed by not exposing certain device nodes, using a process namespace (CLONE_NEWPID) so it can't attach itself as a debugger to other things on the system, etc. etc. But there's no intent in the kernel to make this safe. It's mostly an emergent feature of other things, and emergent features make bad security features.

What you can do is run as not root, which still makes you the same as some other UID on the system, but guarantees that you're not risking increasing privileges. User namespaces give you a few additional features here: first, even the process of entering a chroot / container doesn't require root or a setuid binary, which is neat. Second, even if you're root inside the container, you're not root on the host system in the same sense, and it's just kernel code that's checking for uid == 0 (which should almost all be gone, since they changed the uid_t type in userns-enabled kernels) that thinks you're root.

SELinux might be able to help you here, and I'm not really familiar with what the standard recommendations for SELinux and Docker are. I'd basically consider applying it as if the container didn't exist: if you're comfortable with something running as root with SELinux confinement, then it's definitely fine to run as root inside Docker with SELinux confinement. If not, I wouldn't risk it.

For server containment, you should take a look at https://sandstorm.io/ , which uses user namespaces and runs apps as uid 1000 inside the namespace. This means that it's running with no more privilege than the host user in the worst case.

Re: Docker containers on the desktop

#56

Post by zobzu »

teraflop wrote: post #36
alexlarsson wrote: post #10

This is not sandboxing. Quite the opposite, this gives the apps root access: First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you un…

AFAIK, breaking out of a Docker container isn't as trivial as the first part of your comment suggests. In particular, a Docker container can't run other Docker commands unless you grant it access with something like "docker run -v /var/run/docker.sock:/var/run/docker.sock". Of course, there have been other vulnerabilities in the past allowing containers to get root. And the X11 weakness alone is enough to not treat t…

If you break the app you have +- the same access.. see if you break irssi you're not root either.

This stuff is only sort-of reliable when-containers-dont-have-root-bug-today if you run that as a separate user than yourself in a different X server

So basically not cool.

The way GNOME is doing ACTUAL sandboxing is much neater. Turns out it doesn't use Docker also. Go figure /sarcasm.

Re: Docker containers on the desktop

#57

Post by alexlarsson »

jessfraz wrote: post #30
geofft wrote: post #29

Earlier quoted context omitted.

You wrote, "I know that the rest of my system is completely unaffected from anything the app does." This is unfortunately not true. It's a fun hack, and I think if you said it was a fun hack instead of a security measure you'd have gotten a different reaction. (I agree it's a fun hack! It's just not a security measure.)

The commands I give are fine. The one Alex gives in his comment mounts root into a container, something I am not saying at all or even close doing at all. No one should ever mount root in a container, its common sense.

You didn't give the root command. But the app can easily send keyboard input events to your terminal window injecting that command.

Re: Docker containers on the desktop

#58

Post by alexlarsson »

teraflop wrote: post #36
alexlarsson wrote: post #10

This is not sandboxing. Quite the opposite, this gives the apps root access: First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you un…

AFAIK, breaking out of a Docker container isn't as trivial as the first part of your comment suggests. In particular, a Docker container can't run other Docker commands unless you grant it access with something like "docker run -v /var/run/docker.sock:/var/run/docker.sock". Of course, there have been other vulnerabilities in the past allowing containers to get root. And the X11 weakness alone is enough to not treat t…

Its super easy to get out of this container. Just connect to the x socket, then look for a terminal window, the start injecting keyboard input into it.

Re: Docker containers on the desktop

#60

Post by Iv »

alexlarsson wrote: post #10

This is not sandboxing. Quite the opposite, this gives the apps root access: First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you un…

Yes, I think that it is important to make this point around as docker gains popularity: security is not part of their original design. The problem they apparently wanted to solve initially is the ability for a linux binary to run, whatever its dependencies are, on any system.

It does try to keep containers separated but it does not enforce thatthrough a particularly strong mechanism.

Post reply on HN