31–39 of 39 posts
This is blogspam. The actual guidelines are at 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... )
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…
> 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) [2]: http://capsicum-linux.org/
This is blogspam. The actual guidelines are at 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... )
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... .
Earlier quoted context omitted.
> 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) [2]: http://capsicum-linux.org/
Meh I don’t consider it bad. It’s in FreeBSD. You want it? Run FreeBSD. Waiting for Linux to implement their “version” of capsicum, poorly, Might be a while. Plus you have other great tech like CloudABI in FreeBSD as well which makes it even more compelling.
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.
Earlier quoted context omitted.
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
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.
Earlier quoted context omitted.
Meh I don’t consider it bad. It’s in FreeBSD. You want it? Run FreeBSD. Waiting for Linux to implement their “version” of capsicum, poorly, Might be a while. Plus you have other great tech like CloudABI in FreeBSD as well which makes it even more compelling.
It would be wonderful for FreeBSD as well as Linux if both operating systems supported capsicum. It would mean that both would have the same sandboxing API. Which would make it more likely for application authors to use capsicum, which in turn increases the amount of applications using it. Also why do you assume Linux's implementation would be poor? there's nothing to indicate that it is. Also capsicum is already imp…
Also for sand boxing apps you really should look at CloudABI. Ed has put a ton of work into it.
The last time I looked at capsicum for Linux it wasn’t complete. That’s changed?
Who you may remember.... http://www.ams.org/notices/201402/rnoti-p190.pdf
Earlier quoted context omitted.
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
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.
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.