4 ms·

Broken security boundaries are actively harmful. If you offer something that looks like a security boundary, then people will design their systems on the assump

Broken security boundaries are actively harmful. If you offer something that looks like a security boundary, then people will design their systems on the assumption that it does what it looks like it does. Doubly so if it is actually documented as a security feature. They will then _not_ look into alternative mechanisms to achieve their security goals, even when those alternatives exist and are less susceptible to holes. Yes, the kernel should be fixed. But until the kernel is fixed, distributions should not be enabling broken features by default.

quotemstr 2y ago
This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness is making it hard for application authors to use new features and advance the state of the art. The kernel should not have random knobs for disabling new technology. > But until the kernel is fixed The kernel is in fact fixed. The occasional bug doesn't obviate the maturity of the system. If it did, you wouldn't use Linux at all
- rini17 2y ago
  Attack surface is a thing, still.
- yjftsjthsd-h 2y ago
  > This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness It's not "superstitiousness" when the new features did in fact have vulnerabilities.
  - quotemstr 2y ago
    The superstition lasts a lot longer than the vulnerabilities do.
    - yjftsjthsd-h 2y ago
      Yes, obviously; a feature with a history of vulnerabilities is likely to have more that have not yet been found and patched. It's a guess, but in the but in the face of unknown unknowns it's rational.
      - quotemstr 2y ago
        You know, I'm still unsure about this "thread" concept some programs use. It's kind of insane for ONE program to do TWO THINGS at the SAME TIME. I think it can lead to security problems. Please add a sysctl knob letting me turn off this dangerous technology until we fix all the problems with it.
        yjftsjthsd-h 2y ago
        First: That's a strawman. Nobody's saying we can't ever use new features, just that it's reasonable to be cautious with new code that demonstrably has a history of problems. When io_uring has a few decades under its belt I expect its use to be uncontroversial. Second: That's... not a terrible idea. Concurrency bugs do crop up from time to time. I wouldn't use it for everything (again, we're in the very long tail of concurrency bugs), but having a way to force the system into a mode that couldn't hit them would be nice for high-stakes situations (the same way that Apple's Lockdown Mode disables JIT in the browser). Unfortunately it would probably be more involved than a sysctl.
- hollerith 2y ago
  >The occasional bug doesn't obviate the maturity of the system. Here you are hoping that the reader will equate "mature" with fewer bugs, but in reality the only sense that Linux is obviously and incontestably mature is in the sense of having existed for many years. Have you considered the possibility that Linux is adding security holes at a rate higher than they are being removed? I see a lot of evidence that that is so (and has always been so). There is certainly a lot of new code being added to the project all the time.

quotemstr 2y ago

This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness is making it hard for application authors to use new features and advance the state of the art. The kernel should not have random knobs for disabling new technology. > But until the kernel is fixed The kernel is in fact fixed. The occasional bug doesn't obviate the maturity of the system. If it did, you wouldn't use Linux at all

rini17 2y ago
Attack surface is a thing, still.
yjftsjthsd-h 2y ago
> This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness It's not "superstitiousness" when the new features did in fact have vulnerabilities.
- quotemstr 2y ago
  The superstition lasts a lot longer than the vulnerabilities do.
  - yjftsjthsd-h 2y ago
    Yes, obviously; a feature with a history of vulnerabilities is likely to have more that have not yet been found and patched. It's a guess, but in the but in the face of unknown unknowns it's rational.
    - quotemstr 2y ago
      You know, I'm still unsure about this "thread" concept some programs use. It's kind of insane for ONE program to do TWO THINGS at the SAME TIME. I think it can lead to security problems. Please add a sysctl knob letting me turn off this dangerous technology until we fix all the problems with it.
      - yjftsjthsd-h 2y ago
        First: That's a strawman. Nobody's saying we can't ever use new features, just that it's reasonable to be cautious with new code that demonstrably has a history of problems. When io_uring has a few decades under its belt I expect its use to be uncontroversial. Second: That's... not a terrible idea. Concurrency bugs do crop up from time to time. I wouldn't use it for everything (again, we're in the very long tail of concurrency bugs), but having a way to force the system into a mode that couldn't hit them would be nice for high-stakes situations (the same way that Apple's Lockdown Mode disables JIT in the browser). Unfortunately it would probably be more involved than a sysctl.
hollerith 2y ago
>The occasional bug doesn't obviate the maturity of the system. Here you are hoping that the reader will equate "mature" with fewer bugs, but in reality the only sense that Linux is obviously and incontestably mature is in the sense of having existed for many years. Have you considered the possibility that Linux is adding security holes at a rate higher than they are being removed? I see a lot of evidence that that is so (and has always been so). There is certainly a lot of new code being added to the project all the time.