11–20 of 39 posts
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.
> 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/
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
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.
What prevents you from updating the profile?
Denials by AppArmor (or any other ACL addition) really should have a more verbose diagnostic message AND a dedicated ERRNO that is different from the standard ones.
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…
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/
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
kinda, although you could implement sandboxing with SELinux it's going to take much more effort. SELinux is a Mandatory Access Control Framework and Capsicum is a hybrid Unix capabilities system. While there is overlap in what you can do with them they really our different sets of tools.
Mandatory access controls are for system administrators to lock down and control access on a machine. Capsicum is for application authors to sandbox their application. Ideally they should be used together.
Back to my point that while MAC(SELinux) can be used for sandboxing but will take more effort then using something like capsicum or pledge. With MAC you have to think of all the things you don't want an application to do. With Capsicum or Pledge you only have to think of the things you want your application to do and everything else will be blocked automatically. So for example to sandbox chromium with capsicum it took 100 LOC, to sandbox chromium with SELinux it took 200 LOC so not bad but it doesn't stop IPC primitives. So half the code and more protection.
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…
Which is yet another reason I've come to like BSD jails.
Earlier quoted context omitted.
What prevents you from updating the profile?
The error messages you get are NOT helpful in allowing you to figure out what just went wrong, so if you don't know about it there's a huge cognitive gap because things that SHOULD work just don't for no valid reason. Denials by AppArmor (or any other ACL addition) really should have a more verbose diagnostic message AND a dedicated ERRNO that is different from the standard ones.
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 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.
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.
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.