
Application Container Security Guide [pdf] - philips
https://dx.doi.org/10.6028/NIST.SP.800-190
======
ak217
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 have been doing the heavy lifting in
getting cgroup and namespace functionality working properly and securely - and
without any of the glamorous publicity that Docker and CoreOS get. They use
AppArmor extensively as an "application firewall for syscalls", which may
sound ugly but is the most practical security solution I've seen in this
space.

~~~
2trill2spill
> They use AppArmor extensively as an "application firewall for syscalls",
> which may sound ugly but is the most practical security solution I've seen
> in this space.

Seems like a good use case for Capsicum[1]. Too bad Capsicum hasn't been
merged into the Linux Kernel yet[2].

[1]:
[https://www.freebsd.org/cgi/man.cgi?capsicum(4)](https://www.freebsd.org/cgi/man.cgi?capsicum\(4\))

[2]: [http://capsicum-linux.org/](http://capsicum-linux.org/)

~~~
jlgaddis
Sounds like a good use case for SELinux [0], too, which has already been
merged -- roughly 15 years or so ago.

~~~
weberc2
I'm of the impression that SELinux is much more operationally complex than
AppArmor--so much so that it lends itself to security holes by way of
accidental misconfiguration. This is all hearsay, but I'd like to hear some
good discussion about this.

~~~
jlgaddis
> _... it lends itself to security holes by way of accidental
> misconfiguration._

I'm not sure I understand how SELinux would introduce _additional_ security
issues. It doesn't permit any behavior that wouldn't be allowed if it weren't
in use.

> _... I 'd like to hear some good discussion about this._

Some people seem to have -- for whatever reasons (previous issues or whatever)
-- sworn off SELinux completely which, IMO, is a mistake.

Unfortunately, there are way too many tutorials and how-to guides on the
Internet where step 1 is often "turn off SELinux". Instead of taking the time
to figure out what the problem is and fixing it, they just take the easy route
and get rid of it completely.

I am the opposite. Most of my servers run RHEL/CentOS and I insist that it be
enabled on all of them. This is primarily because I've seen, firsthand,
SELinux prevent a compromise (well, kind of).

In my career, I've had one machine that I had responsible for (even though it
was "shared responsibility") get compromised (that I know of, of course). It
was because of a web application (used by Marketing) where a vulnerability had
been found and a patch had been released but not yet installed. I was on
vacation at the time and, when I returned, just mistakenly assumed that this
had been addressed. An exploit existed and was being used "in the wild" and
this machine was hit.

The first thing that exploit did was to reach out and download the rest of its
toolkit via TFTP. Fortunately, that attempt was prevented by SELinux and
logged. Thanks to that log entry, we began investigating, figured out what
happened, and promptly updated the machine.

So, yeah, SELinux saved our ass once, many years ago, and so now I make sure
that it is enabled everywhere possible. It didn't technically _prevent_ a
compromise but it certainly prevented it from being much, much worse. We were
able to figure out that nothing else happened after the TFTP transfer failed.
The attacker didn't "try again" and we got it patched and back online without
any other issues.

SELinux _is_ complex and requires administrators to learn new things, but it's
nothing that someone running Linux servers isn't used to -- it's just one more
thing you need to learn.

------
storrgie
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.

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

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

------
clhodapp
This is blogspam. The actual guidelines are at
[https://dx.doi.org/10.6028/NIST.SP.800-190](https://dx.doi.org/10.6028/NIST.SP.800-190)
(or if you insist on landing on a page first,
[https://www.nist.gov/publications/application-container-
secu...](https://www.nist.gov/publications/application-container-security-
guide))

~~~
dang
It's perhaps a borderline case, but ok, we'll change the url to that from
[https://coreos.com/blog/coreos-welcomes-nist-container-
secur...](https://coreos.com/blog/coreos-welcomes-nist-container-security-
guidelines).

~~~
clhodapp
Thanks for doing that!

