Live data from Hacker News

Linus Torvalds: “Do No Harm”

lkml.org

41–50 of 233 posts

Re: Linus Torvalds: “Do No Harm”

#41
post #3

Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class of security bugs from being exploited. Grsecurity is a security hardening patchset for Linux that makes deliberate trade-offs in favor of security, sacrificing availability if necessary. This, aside from the political issue, is the main reasons why it's hard t…

> From a security standpoint, when you find an invalid access, and you mitigate it, you've done a great job, and your hardening was successful and you're done. "Look ma, it's not a security issue any more", and you can basically ignore it as "just another bug" that is now in a class that is no longer your problem. So to you, the big win is when the access is _stopped_. That's the end of the story from a security stan…

Fixing all memory corruption bugs is infeasible without fundamentally changing the way Linux is developed. There is so much code (and it’s being added to, changed, etc.) written by humans that make mistakes.

There will always be some bugs that are in between being discovered (by someone, maybe malicious, maybe not), and being fixed. How else do you prevent against vulnerabilities in that stage?

Re: Linus Torvalds: “Do No Harm”

#42
post #15
post #8

Earlier quoted context omitted.

> Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). I'd also like my kernel to halt whenever an assertion does not hold, for the sake of keeping my sanity; not just for security. Why would you not want this?

For the same reason people drive with their “check engine” light on: It’s frequently better to have a working system (i.e. “I’m late for work”), than to chase an indicator that may not represent a real problem (an actual security intrusion).

I can't think of single useful piece of software nowdays that is exposed to public and can't run in active-active load balanced or clustered scenario. If your kernel/system/userland-app misbehaves it simply needs to be shut down, reported and examined. It might have been some random memory block the last time your app made an buffer overflow, but it could as well be the stack pointer next time...

Re: Linus Torvalds: “Do No Harm”

#43
post #8

Earlier quoted context omitted.

> Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). I'd also like my kernel to halt whenever an assertion does not hold, for the sake of keeping my sanity; not just for security. Why would you not want this?

Say there's a minor error in a network driver. Yes, it might be exploitable by a smart person. But the error only triggers once a day when a counter rolls over. Do you really want your box to lock up and panic when this error is encountered, or do you just want your box to keep working. I'm firmly in the first camp (I'll take lock up and freeze thanks) but 99% of users don't care about a bug like that and just want t…

But do you want your box to send silently corrupted data for the next two years? Or would you rather reboot every night, and maybe escalate to your red hat support contract, where someone will then fix the underlying bug (for which you now have crashdumps),

Re: Linus Torvalds: “Do No Harm”

#44

Very pragmatic. He sees software in the overall context of getting a job done with a computer, imperfect though it may be, instead of dying because it was not perfect. Unlike a segfault from a user space program that indeed merits a 'kill', the kernel should strive at all costs to keep running, since kernel panics are so much more inconvenient.

Absolutely not. If “do no harm” is a principle, then the kernel should ensure that no harm is taking place. If flaws within the kernel allow harm to occur while otherwise normal transactions are occurring then it is absolutely preferable to panic and shut down over allowing that potential harm to occur. To suggest otherwise, that detected errors that allow harm should be allowed, is pure insanity. Linus is unquestion…

But as he explains, these are latent bugs. They may or may not be targetted for exploitation yet. Meanwhile hard crashing over them can lead to poor user experience, while throwing up warnings and leading to an actual fix would be better from user PoV, unless of course userspace actually depended on the buggy condition, but that's another discussion.

Re: Linus Torvalds: “Do No Harm”

#45
post #4

Earlier quoted context omitted.

If your security patch kills users' buggy processes or even crash their systems then you are a «bad security person». Please report the bad access first so users and developers of their software have time to fix the bug. Upgrades disabling users' software are a big no-no. After all security is meaningless for a non-working system.

I’m so glad that backwards thinking concepts like this are dominant, otherwise we might actually have secure software! Think about it, an open-source OS is choosing backwards compatibility over security. This would have caused quite the stir in the 90’s Linux community.

They're choosing backwards compatibility over bad security (kill everything instead of reporting and fixing bugs). Applying duct tape everywhere instead of fixing things can hardly be desired.

And as a side note, backwards compatibility is what made windows succeed.

Re: Linus Torvalds: “Do No Harm”

#46

Earlier quoted context omitted.

> From a security standpoint, when you find an invalid access, and you mitigate it, you've done a great job, and your hardening was successful and you're done. "Look ma, it's not a security issue any more", and you can basically ignore it as "just another bug" that is now in a class that is no longer your problem. So to you, the big win is when the access is _stopped_. That's the end of the story from a security stan…

Fixing all memory corruption bugs is infeasible without fundamentally changing the way Linux is developed. There is so much code (and it’s being added to, changed, etc.) written by humans that make mistakes. There will always be some bugs that are in between being discovered (by someone, maybe malicious, maybe not), and being fixed. How else do you prevent against vulnerabilities in that stage?

Linus' response is that calling it an infeasible problem is a cop-out. The right way to go about it is to fix them all, incrementally if need be, and not break userland in the process.

Re: Linus Torvalds: “Do No Harm”

#47
post #42
post #15

Earlier quoted context omitted.

For the same reason people drive with their “check engine” light on: It’s frequently better to have a working system (i.e. “I’m late for work”), than to chase an indicator that may not represent a real problem (an actual security intrusion).

I can't think of single useful piece of software nowdays that is exposed to public and can't run in active-active load balanced or clustered scenario. If your kernel/system/userland-app misbehaves it simply needs to be shut down, reported and examined. It might have been some random memory block the last time your app made an buffer overflow, but it could as well be the stack pointer next time...

Web browsers are, for practical purposes, exposed to the public. Linux doesn't run only on servers.

Re: Linus Torvalds: “Do No Harm”

#48

Very pragmatic. He sees software in the overall context of getting a job done with a computer, imperfect though it may be, instead of dying because it was not perfect. Unlike a segfault from a user space program that indeed merits a 'kill', the kernel should strive at all costs to keep running, since kernel panics are so much more inconvenient.

Absolutely not. If “do no harm” is a principle, then the kernel should ensure that no harm is taking place. If flaws within the kernel allow harm to occur while otherwise normal transactions are occurring then it is absolutely preferable to panic and shut down over allowing that potential harm to occur. To suggest otherwise, that detected errors that allow harm should be allowed, is pure insanity. Linus is unquestion…

You seem to be one of those "security people" Linus refers to. ;)

Harm is relative. You security people think that every single security issue is so important that it doesn't matter what harm mitigating that may cause, it can be done. Well, that is not what Linus thinks.

Kernel may terminate a process because it did something of suspect but doing that may actually cause way _more_ harm.

The philosophy here is that security bugs are just bugs.

Re: Linus Torvalds: “Do No Harm”

#49
post #23

It's interesting to see this laser focus on a particular kind of user. If you're running Linux on a server, you're a user, but unless you're very irresponsible you would probably rather your programs crash than give away private information. Your interface is to a cluster of machines where individual crashes are probably not that big a deal. If you're running Linux via Android, you're a user, but mostly you're a user…

One of the point of Linus is that most of the crashes will not be because of an active attack but because of a possibly latent bug that sometimes appear and might very well be non exploitable. So probably people running server would like to have everything working instead of having random crashes on processes or drivers that are not the core of your service but can affect it. And given the size and complexity of the kernel it would not be strange to have these crashes appear only on certain setups and not necessarily on the ones of the people that are testing it first.

Re: Linus Torvalds: “Do No Harm”

#50
post #8
post #3

Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class of security bugs from being exploited. Grsecurity is a security hardening patchset for Linux that makes deliberate trade-offs in favor of security, sacrificing availability if necessary. This, aside from the political issue, is the main reasons why it's hard t…

> Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). I'd also like my kernel to halt whenever an assertion does not hold, for the sake of keeping my sanity; not just for security. Why would you not want this?

AFAICS, Linus also wants it, but he wants a panic to be preceded by a rather lengthy span with just a warning, allowing the concerned dev to actually fix the error. Essentially he's saying: "take it slow, and don't break user experience."
Post reply on HN