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

Application Container Security Guide [pdf]

dx.doi.org

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Application Container Security Guide [pdf]

#21

Post by AgentME »

ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

What is the state of Docker container security? Is it still the case that root inside of a container trivially equals root outside of the container, or has that been addressed? I thought it had been. I've been finding it hard to find an answer to this.

Re: Application Container Security Guide [pdf]

#22

Post by drewlander »

masterleep wrote: post #11
storrgie wrote: post #4

I like how there is an implied influence (e.g. dockerism) about containers being immutable/ephemeral... meanwhile I've been incredibly happy moving most of my VM deployments over to nspawn because many standards of systems management were anti-patterns in dockerland.

systemd-nspawn certainly deserves more acclaim. It's great, and really easy to use right out of the box.

Absolutely agree. No need for anything fancy, quick and easy to setup and use.

Re: Application Container Security Guide [pdf]

#24

Post by hacknat »

ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

AppArmor actually relies partly on seccomp, which is actually quite fast and is in the kernel.

Re: Application Container Security Guide [pdf]

#25

Post by hacknat »

AgentME wrote: post #21
ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

What is the state of Docker container security? Is it still the case that root inside of a container trivially equals root outside of the container, or has that been addressed? I thought it had been. I've been finding it hard to find an answer to this.

It has been partially addressed you can enable username spacing in docker, but it is not the default. Additionally per tenant user namespacing is not yet possible with docket (though it is in the kernel).

Re: Application Container Security Guide [pdf]

#26

Post by hacknat »

ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

I agree with much of what you said, but I think the word “infancy” is pretty strong. Containers are actually older than VMs (going back to the old tymeshare days of the 60s, but also in Linux right after 2001). Multi-tenant containers are relatively new, but I think this NIST guideline is a pretty thorough.

Re: Application Container Security Guide [pdf]

#27

Post by hacknat »

markc wrote: post #7
ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

There are a few commercial container security products too - twistlock, aquasec, neuvector - for those who can't wait.

Also notary from docker can prevent MIM injection in the layers as they are being uploaded and downloaded (a surprisingly easy task actually, I think someone did it without having to break SSL).

Re: Application Container Security Guide [pdf]

#28

Post by paulddraper »

SteveNuts wrote: post #19
paulddraper wrote: post #6

Earlier quoted context omitted.

AppArmor is probably a good product. Unfortunately, I've been left with a bad taste. MySQL Ubuntu packages pull in AppArmor by default - BY DEFAULT - and include a profile that doesn't let you put your data dir anywhere except for one particular location. And it's virtually impossible to tell why MySQL can write to THAT LOCATION RIGHT THERE where is clearly has the appropriate permissions.

Isn't that one of the main functions of a Mandatory ACL tool like AppArmor/SELinux - not allowing a program to operate outside of the normal confines? I'd be happy to know it was working as indented, and a short google would lead you to the answer. In fact, Digital Ocean's documentation is the first result and it's right there in the steps.

It is the purpose of AppArmor. But in normal land, we just expect documented MySQL options to work.

It really was insane for MySQL package maintainers to make AppArmor the default experience. It ought to have been a separate package, where people that wanted AppArmor could have AppArmor.

Re: Application Container Security Guide [pdf]

#29

Post by TheDong »

AgentME wrote: post #21
ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

What is the state of Docker container security? Is it still the case that root inside of a container trivially equals root outside of the container, or has that been addressed? I thought it had been. I've been finding it hard to find an answer to this.

You'll have a hard time finding people who will say you are secure, but there are no known vulnerabilities allowing breaking out of a default-configuration docker container at this time.

JessFraz has been running https://contained.af/, which is a much more locked-down than the default container, for ages, and no one has broken out and captured the flag yet.

If you do some legwork, it's not too bad currently.

Re: Application Container Security Guide [pdf]

#30

Post by fulafel »

ak217 wrote: post #2

In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…

It's telling that Docker still defaults to running containers as root (without user namespaces to remap UIDs)!
Post reply on HN