Hacker News Reader

Comment by arno1 | Hacker News Reader

I think it should be pretty obvious why people put things into containers :-)

Few main points though, which pushed me making this Docker container:

1. I want to set-up more fences when running the code I don't/can't trust;

2. I don't want to spend time on figuring out how to install Steam (what deps) in a non-Debian (or non-SteamOS) based distro;

3. I like cleanliness: I can erase Steam and all its dependencies in a matter of seconds;

4. Like you said, it was an interesting exercise and it still needs some polishing :-)

And few Pros from my PoV:

- I can have Steam on my Ubuntu/openSUSE/[put any other distro I will want to use] in a short time that Docker takes when downloads this Steam container;

- Since Steam is meant to run in Debian (SteamOS) based distro, it is not a problem anymore, since it is in a container now.

View on HN

So you don't trust application code, but you trust image makers code?.

Yes? (Not the OP)

The image build instructions are pretty easy to audit. And I trust docker (to an extent).

So in my mind it's safer, but not absolutely safe. I just view it as another layer of security :)

This thread is not about to what extent I trust things.

But security-wise, running it in a container is better, than running it without isolation. IMHO.

And of course, no one asks getting this image built by the 3rd party, since the Dockerfile is open, just build it yourself ;-)

There is very little reason to believe that escalated privileges are not possible within a given virtualized environment, at least with current technologies.

Containers are great for development and production on your own infrastructure, or shared infrastructure like GCE or AWS. Security can be had from doing inspected builds, self signing, etc.

For consumers, however, it's a completely different ballgame.

I'd be more worried about the game doing something accidentally bad to my system than deliberate hacking: https://github.com/valvesoftware/steam-for-linux/issues/3671

By the time serious hacking is an issue through Steam, I'd expect containers will be that much better anyhow. For all they can be criticized, and regardless of whether you think some other approach would have been better, they're getting the "trial by fire" treatment. By hook or by crook, in another year or two I expect they'll be as secure as you could ask for.

I'm primarily concerned with escalated privileges in what will become standardized gear for VR and AR viewing...if we start down the path with containerization like I expect we are.

Worn most of the time while a typical user is awake, goggle hacking will represent a very large target with widely varying rewards.

All those Docker commands usually run as root or something equivalent to root. So a container breakout could lead to root on the host system.

I think kordless is claiming that using Docker here could increase the severity of an attack; otherwise it doesn't seem like putting up another barrier could hurt security, even if it is later broken.

My claim would be applied to all virtualized environments, including containers and VMs - not just Docker. Microkernels have a decent shot at keeping the security issue at bay, but even then it can't keep them out forever.

Everything falls to hacking eventually. That's the nature of it, at least till now.

I would note that Docker is primarily a tool for developers and operations folk who are also the author of the software being run. Docker itself is not the risk here, but using it for some use cases may very well be.

I would say, using a Docker would move the vector of attack to a Docker engine and a Linux kernel implementation of cgroups, naming spaces.

But it would still help in preventing such bugs as https://github.com/valvesoftware/steam-for-linux/issues/3671

HN discussion: https://news.ycombinator.com/item?id=8896186

Containers are not isolated from host system. They are separated. Isolated containers will have performance and features similar to User Mode Linux.

Isolated or separated (from the host system). Both words will work when context is clear. Or it can confuse, when context was not specified, which is in my case.

What I actually meant is that I'd rather run an isolated (separated) process from other processes and the file-system space (and the other isolation features which cgroups are giving us), not meaning isolation from the host system.

With the cgroups/namespaces it's a process isolation (or separation, whatever wording you prefer). In the Linux kernel documentation they also use isolation wording. ;-)

I think the parent author meant they trust the explicit and narrow boundaries the application code is permitted to run in.

Fundamentally, it is fewer things that I _have_ to trust. The shim which defines an image should be much easier to grok than the entire application.

He can always check the image specification, no?

There's a Steam overlay in Gentoo, and it mostly works, but lately I've had a lot of issues with ATI's open source drivers and Steam, to the point where I just setup a windows machine for games.

This looks really promising though, and shows a practical use case for docker.

Reply on news.ycombinator.com