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

61–70 of 76 posts

Re: Docker containers on the desktop

#61

Post by tmikaeld »

SEJeff wrote: post #51
alexlarsson wrote: post #20

Earlier quoted context omitted.

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?

Wayland sessions are separated from each other.

Re: Docker containers on the desktop

#62

Post by amouat »

This reminds me of the subuser project (http://subuser.org/) which is basically about using Docker to achieve sandboxing - the project is effectively aiming to build a linux package manager out of Docker.

Several commenters have pointed out the very real security issues with opening the X11 port. This is true, but you could use ssh forwarding or VNC (at a considerable performance penalty). I believe the other security issues (mainly related to PID 0 and which user processes are run at) will be solved shortly. Running applications in Docker is never going to be as secure as running an app in a full VM, but it can definitely be better than trusting random code on the internet (the recent Steam client issue springs to mind).

Re: Docker containers on the desktop

#64

Post by digi_owl »

jacoplane wrote: post #8
api wrote: post #2

The need for stuff like Docker is an admission that OS privilege isolation and resource management is woefully inadequate.

Linus agrees: https://www.youtube.com/watch?v=5PmHRSeA2c8#t=298

What i find odd is that he is ranting as if it is a code problem when it is a package manager problem.

Unless i am badly off the mark, ld will use soname to tell lib v1.0 from v1.1 or v5.97. But the problem is with package manager flatly refusing to have anything to do with installing multiple lib versions side by side.

That is, if they have the same package name. End result is that one distro use glib3.xyz to designate glib 3.x, while another use glib-3.xyz Yet another use glib.3.xyz.

They all hold the same files, but for the package managers they are different packages. And will resolve dependencies based on that.

Applying containers and/or sandboxes to this is a Will E. Coyote solution...

Re: Docker containers on the desktop

#65

Post by eropple »

burke wrote: post #5
0x0 wrote: post #4

Are Docker containers actually sensibly secure as sandboxes? I thought there were still some gaps that needed to be closed in the underlying tech for it to be as safe as virtualization?

It's a lot better than no attempt at sandboxing, but ultimately you're still at the mercy of a late addition to the linux kernel (cgroups), which isn't exactly the safest codebase to make major changes like this in. Denial of Service attacks are probably more straightforward than in a virtualized environment; I'm sure you could find a way to starve the kernel for something. That said, there's currently no trivial "no…

I've said this elsewhere in the thread, but this is not better than "no sandboxing". "No sandboxing" doesn't run applications as PID 0 in the host kernel.

Please stop repeating this. Docker is not a security tool, apparently by their own decision. It hurts people to have that be part of the common knowledge.

Re: Docker containers on the desktop

#66

Post by jdub »

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…

Just so everyone knows, this is Alex "I have a weird interest in application bundling systems" Larsson, who is doing some badass bleeding edge work on full on sandboxed desktop applications on Linux. :-)

http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe...

http://www.youtube.com/watch?v=t-2a_XYJPEY

Like Ron Burgundy, he's... "kind of a big deal".

(Suffer the compliments, Alex.)

Re: Docker containers on the desktop

#67

Post by kentonv »

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…

The reason you don't hear about Docker breakouts is because Docker never claimed to be a secure sandbox in the first place, so a breakout is a non-event.

Note that local privilege escalation exploits in Linux are found regularly, like on a monthly basis, and every one is likely a Docker breakout.

geofft mentioned Sandstorm -- my project -- which actually does claim to be a sandbox, and isn't affected by most of these kernel exploits. Here's a blog post discussing the differences:

https://blog.sandstorm.io/news/2014-08-13-sandbox-security.h...

Re: Docker containers on the desktop

#69

Post by CameronNemo »

digi_owl wrote: post #64
jacoplane wrote: post #8

Earlier quoted context omitted.

Linus agrees: https://www.youtube.com/watch?v=5PmHRSeA2c8#t=298

What i find odd is that he is ranting as if it is a code problem when it is a package manager problem. Unless i am badly off the mark, ld will use soname to tell lib v1.0 from v1.1 or v5.97. But the problem is with package manager flatly refusing to have anything to do with installing multiple lib versions side by side. That is, if they have the same package name. End result is that one distro use glib3.xyz to design…

It is not just this. It is also that RHEL 6 will have libfoo4, while Ubuntu 14.04 will have libfoo6, and then Debian Wheezy will have libfoo5. Even if the way the packages dependencies were expressed (libfoo-1-3 vs. libfoo3) were the same, the constant ABI breakage would be harmful.

Re: Docker containers on the desktop

#70

Post by digi_owl »

CameronNemo wrote: post #69
digi_owl wrote: post #64

Earlier quoted context omitted.

What i find odd is that he is ranting as if it is a code problem when it is a package manager problem. Unless i am badly off the mark, ld will use soname to tell lib v1.0 from v1.1 or v5.97. But the problem is with package manager flatly refusing to have anything to do with installing multiple lib versions side by side. That is, if they have the same package name. End result is that one distro use glib3.xyz to design…

It is not just this. It is also that RHEL 6 will have libfoo4, while Ubuntu 14.04 will have libfoo6, and then Debian Wheezy will have libfoo5. Even if the way the packages dependencies were expressed (libfoo-1-3 vs. libfoo3) were the same, the constant ABI breakage would be harmful.

But that problem is largely because of what i started out with, that their package managers can't handle having multiple version of libfoo installed under the same package name. Even tough ld and friends can via soname.

So they "avoid" it by insisting on using a specific version for the duration of the distro version.

Post reply on HN