Docker recently published a new white paper detailing security and Docker containers.  There are some really good insights and our approach to supporting both containers and VMs with unRAID is validated in this document from Docker themselves.  Two quotes I think are worth mentioning here:

 

Containerization does provide isolation for running applications

on bare-metal, which protects the machine from a large array of

threats and is sufficient for a wide range of use cases. Users in

the following scenarios may not be good candidates to use VMs

and can instead use containers; performance-critical applications

running on a single-tenant private cloud, where cross-tenant or

cross-application attacks are not as much of a concern; or they

are using specialized hardware which cannot be passed through

to a VM, or which hardware that offers direct-memory-access,

thus nullifying the isolation benefits of virtualization. Many users of

GPU computing are in this position.

 

Containers and Virtual Machines (VMs) can be deployed

together to provide additional layers of isolation and security

for selected services.

 

Here's a link to the full white paper:

 

https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf

Containers and Virtual Machines (VMs) can be deployed

together to provide additional layers of isolation and security

for selected services.

 

 

can't comment on the security side of things, but will say that dockers and VM's can complement each other.

ok, i'm surprised i understood the majority of that, lol.

Don't know if our use case is affected by this bug. What do our docker developers think of this?

 

reventlov.com/advisories/using-the-docker-command-to-root-the-host

Don't know if our use case is affected by this bug. What do our docker developers think of this?

 

reventlov.com/advisories/using-the-docker-command-to-root-the-host

 

if it's something by design, i'm not sure it qualifies as a bug.

Don't know if our use case is affected by this bug. What do our docker developers think of this?

 

reventlov.com/advisories/using-the-docker-command-to-root-the-host

By docker developers, so you mean container authors here?  I assume so since docker themselves says this isn't a bug (noted inside the post itself at the end).

 

Its definitely not a bug that docker can have privileged access to the system. That is completely intentional and by design.

Sorry for being unclear. Yes I meant "our" developers here creating all "our" containers.

Don't know a lot about developing, just wanted to let you guys know. Haven't even read the whole report...

 

If it's intentional then I guess everything is OK. The headline was just a scary read ;-)

Sorry for being unclear. Yes I meant "our" developers here creating all "our" containers.

Don't know a lot about developing, just wanted to let you guys know. Haven't even read the whole report...

 

If it's intentional then I guess everything is OK. The headline was just a scary read ;-)

Yeah, you can scare yourself by going to google and searching "<insert technology here> security". Every technology is bound to have some security issues once and a while. Its the ease of exploitation and level of risk that you have to take into account.  But in this instance, its just the authors misunderstanding of what docker is designed to do.

 

Think of Docker as like an after market turbo kit for your car. It's not part of the car you bought, but man it makes the thing fast and powerful. Now could a turbo kit work if it didn't have access to the engine compartment?

Think of Docker as like an after market turbo kit for your car. It's not part of the car you bought, but man it makes the thing fast and powerful. Now could a turbo kit work if it didn't have access to the engine compartment?

;D

Pipe going up front goes to the engine compartment, giving it access .  Don't think I'd want that near the gas tank myself, lol.

 

 

Pipe going up front goes to the engine compartment, giving it access .  Don't think I'd want that near the gas tank myself, lol.

 

^^^ since a turbo's job is to increase effiecency in the combustion chamber, i'd say it's a given it has access to the engine compartment, lol.

 

actually this model better fits the docker one, it's not in the engine compartment itself , it's outside of it but has access to the key bit of the engine.

 

so jonp's point stands.

 

 

Pipe going up front goes to the engine compartment, giving it access .  Don't think I'd want that near the gas tank myself, lol.

 

^^^ since a turbo's job is to increase effiecency in the combustion chamber, i'd say it's a given it has access to the engine compartment, lol.

 

actually this model better fits the docker one, it's not in the engine compartment itself , it's outside of it but has access to the key bit of the engine.

 

so jonp's point stands.

I was gonna reply earlier that it'd be pretty hard for a turbo to work without being able to access the engine, regardless of the housing, but figured it would only be a matter of time before someone else made that point for me. Thanks Sparkly!  I still giggle every time I read your name ;-)

Thanks, everything is vroom vroom to me now!

Hate to think what would happen to that installation if, like I did the other evening, it has to drive through a three feet deep flood,

 

BTW, since the pic comes from a Lexus BBS, I presume that the vehicle is a Lexus - can anyone identify the model?  SC430, perhaps?

BTW, since the pic comes from a Lexus BBS, I presume that the vehicle is a Lexus - can anyone identify the model?  SC430, perhaps?

Ironically, no, it's a Pontiac Firebird T/A, probably a '99 or so.

I dont think this is a clear cut problem that users will understand. Everyone has been telling users that containers isolate applications from other containers and the host OS. More than that it has always been touted as a core concept and it is indeed a brilliant one. I cant think of a single docker thing that contradicted this so users can be forgiven for thinking it is not an issue.

 

I believe it is an issue as simply put I do not see it being hard to manipulate this "by design" concept to nefarious ends. In fact I think it would be rather easy to trick users into running bad things as they believe docker containers are silo'd off.

 

I can see this "by design" issue magically quietly being addressed later, until then in terms of our community we really do need to step towards a peer review group. I realize we cannot sanction every container at the LT level but users inherently trust things they see here and by proxy we could have trust escalation abuse.