5 ms·

This is a horrible approach to security. If you only secure against attacks you expect, you're gonna have a bad time.

deleted 9y ago
[deleted]
toomuchtodo 9y ago
Security is about risk mitigation. You cannot derisk entirely, so you make tradeoffs. Without knowing all of the parameters, it’s disingenuous to say it’s a horrible approach to security. The most secure computer is powered off, enclosed in concrete 6 feet below the surface of the earth. It is not very useful though.
- em3rgent0rdr 9y ago
  Reminds me of Battlestar Galactica. The humans were so (wisely) fearful of the Cylons that their ship computers were not networked in anyway. For their risk/reward trade-off curve, the benefit from having computer networks were not worth the risk of the Cylons being able to compromise the entire ship. All communication was either verbal or done via fax printed to paper and so had to go through human intermediaries.
  - toomuchtodo 9y ago
    Good catch!
- userbinator 9y ago
  Very much this. In the real world, basically no one will make their house entirely bulletproof and never go outside just because of the possibility that someone could shoot them. Everyone knows that could happen, but is fine with the risk. "100% secure" is unattainable, and to attempt to achieve it to the exclusion of all other concerns is probably a very bad idea.
merb 9y ago
if you do not apply spectre/meltdown migtation on non virtualized hardware which only you control you are safe. of course a malicious process could do harm without them, but a malicious process probably can be as harmful, even if you have the patches applied. basically we need these patches since on the internet a ton of stuff lives on virtualized hardware and there you can actually be harmful to other vms or even the host itself. basically spectre/meltdown needs to be applied in hosted environments and on clients. on everything else it's way less scary than on those two environments.
- msbarnett 9y ago
  Do you also run all processes on your server as root? If you’re not going to apply patches that close privilege escalation bugs, you might as well. You’re putting all your security eggs in one basket.
  - merb 9y ago
    Well a lot of processes run as Root anyway. Also if possible i run as few processes as possible
    - pixl97 9y ago
      >Well a lot of processes run as Root anyway. Then you didn't listen to DJB like 15 years ago. Moreso, your processes shouldn't be running under the same username. Principle of least user authorization people.
      - merb 9y ago
        please just install a linux distribution and run ps aux. a ton of stuff just runs as root. either because there is no other way or because it's a bad default.
        msbarnett 9y ago
        Yeah it’s your job as a Unix dev or admin to not stick with crummy but convenient defaults, kid. Nothing exposed to the web or touching anything exposed to the web should be running as root. Each thing should be running under its own, very limited, user and group. If something gets hacked, you want it to be as least privileged as possible. We know how Unix works. We’re telling you because you clearly are out of your depth. If you don’t understand that you have no business maintaining anything on the internet.
cookiecaper 9y ago
Some things are just not applicable. There's no point adding another padlock to the outside wall of Fort Knox. If untrusted users don't send instructions to the same physical CPU that you're using, Meltdown/Spectre are not relevant. I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PTI needs to be run within guest kernels if the host already has the mitigation (effectively creating a double-hit from PTI in both the guest and host kernel), or that even if PTI is needed in both kernels now, that it will be needed long-term. We also need to figure out what type of Spectre mitigations need to be performed within the guest if the host system has the new microcode that selectively disables branch prediction. The short answer is that it's going to take another 4-6 weeks before even the kernel devs have a firm grasp of what's useful/necessary to mitigate this and for things to settle into place, as Greg K-H blogged about earlier. At that point, we should have a more realistic perspective on the long-term performance impact.
- sigmar 9y ago
  >There's no point adding another padlock to the outside wall of Fort Knox. Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
- pixl97 9y ago
  In the past if you had a RCE that only got user level access and that user was very locked down there was only a limited amount of damage they could have done. Now with meltdown, every RCE is a full information loss at system level exploit.
PascLeRasc 9y ago
On the other hand, if you aren't affected by what a successful attacker can do, you're in a good place.

deleted 9y ago

[deleted]

Security is about risk mitigation. You cannot derisk entirely, so you make tradeoffs. Without knowing all of the parameters, it’s disingenuous to say it’s a horrible approach to security. The most secure computer is powered off, enclosed in concrete 6 feet below the surface of the earth. It is not very useful though.

em3rgent0rdr 9y ago
Reminds me of Battlestar Galactica. The humans were so (wisely) fearful of the Cylons that their ship computers were not networked in anyway. For their risk/reward trade-off curve, the benefit from having computer networks were not worth the risk of the Cylons being able to compromise the entire ship. All communication was either verbal or done via fax printed to paper and so had to go through human intermediaries.
- toomuchtodo 9y ago
  Good catch!
userbinator 9y ago
Very much this. In the real world, basically no one will make their house entirely bulletproof and never go outside just because of the possibility that someone could shoot them. Everyone knows that could happen, but is fine with the risk. "100% secure" is unattainable, and to attempt to achieve it to the exclusion of all other concerns is probably a very bad idea.

merb 9y ago

if you do not apply spectre/meltdown migtation on non virtualized hardware which only you control you are safe. of course a malicious process could do harm without them, but a malicious process probably can be as harmful, even if you have the patches applied. basically we need these patches since on the internet a ton of stuff lives on virtualized hardware and there you can actually be harmful to other vms or even the host itself. basically spectre/meltdown needs to be applied in hosted environments and on clients. on everything else it's way less scary than on those two environments.

msbarnett 9y ago
Do you also run all processes on your server as root? If you’re not going to apply patches that close privilege escalation bugs, you might as well. You’re putting all your security eggs in one basket.
- merb 9y ago
  Well a lot of processes run as Root anyway. Also if possible i run as few processes as possible
  - pixl97 9y ago
    >Well a lot of processes run as Root anyway. Then you didn't listen to DJB like 15 years ago. Moreso, your processes shouldn't be running under the same username. Principle of least user authorization people.
    - merb 9y ago
      please just install a linux distribution and run ps aux. a ton of stuff just runs as root. either because there is no other way or because it's a bad default.
      - msbarnett 9y ago
        Yeah it’s your job as a Unix dev or admin to not stick with crummy but convenient defaults, kid. Nothing exposed to the web or touching anything exposed to the web should be running as root. Each thing should be running under its own, very limited, user and group. If something gets hacked, you want it to be as least privileged as possible. We know how Unix works. We’re telling you because you clearly are out of your depth. If you don’t understand that you have no business maintaining anything on the internet.

cookiecaper 9y ago

Some things are just not applicable. There's no point adding another padlock to the outside wall of Fort Knox. If untrusted users don't send instructions to the same physical CPU that you're using, Meltdown/Spectre are not relevant. I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PTI needs to be run within guest kernels if the host already has the mitigation (effectively creating a double-hit from PTI in both the guest and host kernel), or that even if PTI is needed in both kernels now, that it will be needed long-term. We also need to figure out what type of Spectre mitigations need to be performed within the guest if the host system has the new microcode that selectively disables branch prediction. The short answer is that it's going to take another 4-6 weeks before even the kernel devs have a firm grasp of what's useful/necessary to mitigate this and for things to settle into place, as Greg K-H blogged about earlier. At that point, we should have a more realistic perspective on the long-term performance impact.

sigmar 9y ago
>There's no point adding another padlock to the outside wall of Fort Knox. Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
pixl97 9y ago
In the past if you had a RCE that only got user level access and that user was very locked down there was only a limited amount of damage they could have done. Now with meltdown, every RCE is a full information loss at system level exploit.

PascLeRasc 9y ago

On the other hand, if you aren't affected by what a successful attacker can do, you're in a good place.