6 ms·

Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the abili

Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in rust Even just considering Linux security itself: there are so, so many ways OS security can break besides a slight (you’re going to have to use unsafe a whole lot) increase in memory safety

jvanderbot 3y ago
The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.
- meltyness 3y ago
  Just the other day they were full kum ba yah over a holiday-time-released feature that's likely going to greatly increase the likelihood of building race conditions and deadlocks. https://news.ycombinator.com/item?id=38721039 https://news.ycombinator.com/item?id=38721039
  - jvanderbot 3y ago
    I know it's the curmudgeon NIMBY in me, and I love Rust and use it daily, but it's starting to feel like the worst of the JS crowd scribbled in grandpa's ANSI C books just to make him mad. I am super happy with most features, but demand is demand and people demand runtimes. As a chimera it perfectly represents the modern world.
  - zanellato19 3y ago
    This is such a bizarre take on the stabilization of async that I can't even tell if you are being serious or just hate Rust.
  - dartos 3y ago
    How do you figure? Is it just because it makes async possible?
    - meltyness 3y ago
      https://rust-lang.github.io/async-book/03_async_await/01_chapter.html#awaiting-on-a-multithreaded-executor https://rust-lang.github.io/async-book/03_async_await/01_cha... Is this all information that should be communicated to a programmer, or is all this info something that should be automatically assessed by a compiler with clear responses automatically to all possible situations specified, black and white, in the code? If so, if it is the responsibility of the compiler, why release a version of the language, stabilize a spec, where that's not the case?
  - jcgrillo 3y ago
    To be clear you're talking about async fn and impl trait in return position in traits? If so, how does that impact the likelihood one way or the other of race conditions or deadlocks?
- fires10 3y ago
  Can you expound in this some? I am not fully grasping your point. Are you saying "building safe by default" is a bad thing or assuming "safe forever" is a bad thing. Or are you saying something entirely different?
  - jvanderbot 3y ago
    I said "the idea of using memory safe languages is great!" And "using memory safe languages does not eliminate attack surface". (It's pre coffee here so I appreciate your probe) I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.
    - insanitybit 3y ago
      The premise of my post was "imagine a memory safe kernel". I repeatedly use the word "imagine".
      - yjftsjthsd-h 3y ago
        The disagreement is that you wrote "imagine a memory safe kernel" but appear to have meant "imagine a kernel with zero vulnerabilities of any kind", and those things are not equivalent.
  - RHSeeger 3y ago
    I expect it's likely more of "memory safety in a language doesn't make it _safe_, it makes it less vulnerable". It removes _some_ issues, in the same way that a language with static types removes some ways a program can be wrong, it doesn't make it correct.
    - chatmasta 3y ago
      The problem is the word "safe," which is inherently ambiguous. Safe from what? A better term would be "correct," because at least that implies there is some spec to which the developer expects the program to conform (assuming the spec itself is "correct" and devoid of design flaws).
- a-dub 3y ago
  serious question: how much additional safety do you get over best practices and tooling in modern c++?
  - jvanderbot 3y ago
    It's not possible for me to say. Clearly you can only do worse in Rust than you'd have with perfect C. But what's that? The question is: what is the expected loss (time, bugs, exploits that lead to crashes or injury or death or financial catastrophe) with Rust vs other languages. Unfortunately that's not the conversation we have. We instead have absolutism re managed memory, which does account for about half of known security flaws that have been discovered and patched. Removing half of bugs in one fell swoop sounds amazing. It's not that we can't remove those bugs other ways. Maybe modern c++ can cut bugs in half at compile time too. But Rust seems nicer to play with and doesn't require much more than what it has out of the box. Also it's shiny and new. Given that Rust is making its way into platforms that Cpp struggled into, it's potentially moot. I sincerely doubt Linux will accept Cpp, but we're on the cusp of Rust in Linux.
    - steveklabnik 3y ago
      > Clearly you can only do worse in Rust than you'd have with perfect C. Is this clear? Why would the best Rust be worse than the best C?
      - SirMittens 3y ago
        I assume parent probably meant that the worse you can do in rust (e.g use of unsafe... etc) would just put you back at C level of memory safety.
      - Anonbrit 3y ago
        Rust has a few small but unavoidable runtime overheads compared to the best C (maybe they can be avoided with the right unsafe usage but that removed most of the benefits of rust). They are difficult to see the affect of without micro-benchmarking in my very limited experience, but C can avoid them
- atq2119 3y ago
  JS and Rust are memory safe languages with a culture of pulling in hundreds if not thousands of dependencies. So unfortunately, in terms of culture, at least those languages are not Pareto improvements.
  - chatmasta 3y ago
    Also a lot of "in Rust" rewrites include a substantial amount of unsafe FFI calls to the original C libraries...
insanitybit 3y ago
[flagged]
- opportune 3y ago
  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.
  - insanitybit 3y ago
    > 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.
- NooneAtAll3 3y ago
  >> Memory safety isn’t why containers are considered insufficient as a security boundary. > 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"
- t8sr 3y ago
  > 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.

jvanderbot 3y ago

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

meltyness 3y ago
Just the other day they were full kum ba yah over a holiday-time-released feature that's likely going to greatly increase the likelihood of building race conditions and deadlocks. https://news.ycombinator.com/item?id=38721039 https://news.ycombinator.com/item?id=38721039
- jvanderbot 3y ago
  I know it's the curmudgeon NIMBY in me, and I love Rust and use it daily, but it's starting to feel like the worst of the JS crowd scribbled in grandpa's ANSI C books just to make him mad. I am super happy with most features, but demand is demand and people demand runtimes. As a chimera it perfectly represents the modern world.
- zanellato19 3y ago
  This is such a bizarre take on the stabilization of async that I can't even tell if you are being serious or just hate Rust.
- dartos 3y ago
  How do you figure? Is it just because it makes async possible?
  - meltyness 3y ago
    https://rust-lang.github.io/async-book/03_async_await/01_chapter.html#awaiting-on-a-multithreaded-executor https://rust-lang.github.io/async-book/03_async_await/01_cha... Is this all information that should be communicated to a programmer, or is all this info something that should be automatically assessed by a compiler with clear responses automatically to all possible situations specified, black and white, in the code? If so, if it is the responsibility of the compiler, why release a version of the language, stabilize a spec, where that's not the case?
- jcgrillo 3y ago
  To be clear you're talking about async fn and impl trait in return position in traits? If so, how does that impact the likelihood one way or the other of race conditions or deadlocks?
fires10 3y ago
Can you expound in this some? I am not fully grasping your point. Are you saying "building safe by default" is a bad thing or assuming "safe forever" is a bad thing. Or are you saying something entirely different?
- jvanderbot 3y ago
  I said "the idea of using memory safe languages is great!" And "using memory safe languages does not eliminate attack surface". (It's pre coffee here so I appreciate your probe) I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.
  - insanitybit 3y ago
    The premise of my post was "imagine a memory safe kernel". I repeatedly use the word "imagine".
    - yjftsjthsd-h 3y ago
      The disagreement is that you wrote "imagine a memory safe kernel" but appear to have meant "imagine a kernel with zero vulnerabilities of any kind", and those things are not equivalent.
- RHSeeger 3y ago
  I expect it's likely more of "memory safety in a language doesn't make it _safe_, it makes it less vulnerable". It removes _some_ issues, in the same way that a language with static types removes some ways a program can be wrong, it doesn't make it correct.
  - chatmasta 3y ago
    The problem is the word "safe," which is inherently ambiguous. Safe from what? A better term would be "correct," because at least that implies there is some spec to which the developer expects the program to conform (assuming the spec itself is "correct" and devoid of design flaws).
a-dub 3y ago
serious question: how much additional safety do you get over best practices and tooling in modern c++?
- jvanderbot 3y ago
  It's not possible for me to say. Clearly you can only do worse in Rust than you'd have with perfect C. But what's that? The question is: what is the expected loss (time, bugs, exploits that lead to crashes or injury or death or financial catastrophe) with Rust vs other languages. Unfortunately that's not the conversation we have. We instead have absolutism re managed memory, which does account for about half of known security flaws that have been discovered and patched. Removing half of bugs in one fell swoop sounds amazing. It's not that we can't remove those bugs other ways. Maybe modern c++ can cut bugs in half at compile time too. But Rust seems nicer to play with and doesn't require much more than what it has out of the box. Also it's shiny and new. Given that Rust is making its way into platforms that Cpp struggled into, it's potentially moot. I sincerely doubt Linux will accept Cpp, but we're on the cusp of Rust in Linux.
  - steveklabnik 3y ago
    > Clearly you can only do worse in Rust than you'd have with perfect C. Is this clear? Why would the best Rust be worse than the best C?
    - SirMittens 3y ago
      I assume parent probably meant that the worse you can do in rust (e.g use of unsafe... etc) would just put you back at C level of memory safety.
    - Anonbrit 3y ago
      Rust has a few small but unavoidable runtime overheads compared to the best C (maybe they can be avoided with the right unsafe usage but that removed most of the benefits of rust). They are difficult to see the affect of without micro-benchmarking in my very limited experience, but C can avoid them
atq2119 3y ago
JS and Rust are memory safe languages with a culture of pulling in hundreds if not thousands of dependencies. So unfortunately, in terms of culture, at least those languages are not Pareto improvements.
- chatmasta 3y ago
  Also a lot of "in Rust" rewrites include a substantial amount of unsafe FFI calls to the original C libraries...

insanitybit 3y ago

[flagged]

opportune 3y ago
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.
- insanitybit 3y ago
  > 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.
NooneAtAll3 3y ago
>> Memory safety isn’t why containers are considered insufficient as a security boundary. > 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"
t8sr 3y ago
> 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.