> Memory safety is the primary issue with containers as a security boundary.
I don't know where you're getting your information, but this is NOT the consensus on the LMKL, among most Linux kernel people or at any serious large scale tech company.
If you wish to learn about this stuff, lwn.net has a good series of articles on the problems people are actually working on. Most of the problems are related to namespace confusion, privilege escalation through, e.g. block-level access to the filesystem, etc.
> Sometimes the issues are not memory safety ones! But many, most are.
Huge citation needed. In 15 years of security, 8 in Linux kernel security, I have seen maybe one practical exploit related to containers that boiled down to a C-level memory issue.
> That's on you, but I'd be happy to explain more to you if you have questions.
No, you're very confidently stating things that are at the very least debatable. This thread has people doing kernel security as a day job.
Respectfully, do you know what a container actually is? (I’m guessing you think it’s docker, which is a common misconception)
The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preventing these syscalls from doing bad shit.
> Respectfully, do you know what a container actually is?
I am extremely familiar with containers, the linux kernel, and virtual machines. In particular from a security perspective.
> The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself.
Namespaces, such as process namespaces, file namespaces, user namespaces, etc, will prevent a container from interacting with another container without even getting into the fact that you can leverage DAC to do so further.
This is getting a bit defensive. I think people are interpreting your post as saying all safety is guaranteed by using memory safety, but you rightly walk it back in comments to mean it addresses "primary" security problems.
It's just silly. I wrote an "imagine if we could trust the kernel as a boundary" and I get 100 posts about the same misconceptions. If people read into my post that I think a Rust kernel would solve all problems, perhaps I was overly simplistic with my language.
t8sr|2 years ago
I don't know where you're getting your information, but this is NOT the consensus on the LMKL, among most Linux kernel people or at any serious large scale tech company.
If you wish to learn about this stuff, lwn.net has a good series of articles on the problems people are actually working on. Most of the problems are related to namespace confusion, privilege escalation through, e.g. block-level access to the filesystem, etc.
> Sometimes the issues are not memory safety ones! But many, most are.
Huge citation needed. In 15 years of security, 8 in Linux kernel security, I have seen maybe one practical exploit related to containers that boiled down to a C-level memory issue.
> That's on you, but I'd be happy to explain more to you if you have questions.
No, you're very confidently stating things that are at the very least debatable. This thread has people doing kernel security as a day job.
unknown|2 years ago
[deleted]
opportune|2 years ago
The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preventing these syscalls from doing bad shit.
insanitybit|2 years ago
I am extremely familiar with containers, the linux kernel, and virtual machines. In particular from a security perspective.
> The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself.
Namespaces, such as process namespaces, file namespaces, user namespaces, etc, will prevent a container from interacting with another container without even getting into the fact that you can leverage DAC to do so further.
NooneAtAll3|2 years ago
> Memory safety is the primary issue with containers as a security boundary.
"No it isn't" "Yes it is" "No it isn't" "Yes it is"
jvanderbot|2 years ago
That's it.
insanitybit|2 years ago