4 ms·

> Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve.

> Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. I will refer you to: https://blog.jessfraz.com/post/containers-security-and-echo-chambers/ https://blog.jessfraz.com/post/containers-security-and-echo-...

dijit 4y ago
I quite like Jessie Frazzel, so it pains me to say this: Reality is not in line with what she says in this post. The paper she's referring to specifically calls out hardening guidelines for containers to make them more secure, but that is not how containers are run, even on GKE (a platform I consider to be the defacto gold standard for container platforms). Aside from the issue of signing (which, is a continued problem in windows-land FYI) not being the default, even seccomp is disabled by default in the overwhelming majority of cases. Even flatpak only uses seccomp to filter "the most risky syscalls" (perf, ptrace, weird network protocols like DECnet and recursive namespaces). What I'm trying to say is: ticking the box that seccomp is enabled is not useful if you're allowing bind mounts. Why would you allow bind mounts? that's insane?! Well, usability is a trade-off my friend, and telling people their fancy sandboxed application can't read their ~/Downloads folder is not going to fly. The only solution is an all-encompassing one, with a prompt system like macos has to allow only a selected number of mounts, but that's going to be handled at a completely different level than seccomp itself, and seccomp will be explicitly permitted to do this; thus protections against this one specific thing could be thwarted. This is but one of many things. Solving security for the general case is really hard. As Jess herself points out in that article.

4 ms·

> Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve.

by ryukafalz 4y ago

dijit 4y ago
I quite like Jessie Frazzel, so it pains me to say this: Reality is not in line with what she says in this post. The paper she's referring to specifically calls out hardening guidelines for containers to make them more secure, but that is not how containers are run, even on GKE (a platform I consider to be the defacto gold standard for container platforms). Aside from the issue of signing (which, is a continued problem in windows-land FYI) not being the default, even seccomp is disabled by default in the overwhelming majority of cases. Even flatpak only uses seccomp to filter "the most risky syscalls" (perf, ptrace, weird network protocols like DECnet and recursive namespaces). What I'm trying to say is: ticking the box that seccomp is enabled is not useful if you're allowing bind mounts. Why would you allow bind mounts? that's insane?! Well, usability is a trade-off my friend, and telling people their fancy sandboxed application can't read their ~/Downloads folder is not going to fly. The only solution is an all-encompassing one, with a prompt system like macos has to allow only a selected number of mounts, but that's going to be handled at a completely different level than seccomp itself, and seccomp will be explicitly permitted to do this; thus protections against this one specific thing could be thwarted. This is but one of many things. Solving security for the general case is really hard. As Jess herself points out in that article.