Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds: “Do No Harm”

lkml.org

Post reply on HN
Print view View original

71–80 of 233 posts

Re: Linus Torvalds: “Do No Harm”

#71

Post by teamhappy »

drinchev wrote: post #34
amelius wrote: 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?

Linux is used in so many critical systems. What happens when a security bug stops the ventilating machine of a person lying in hospital bed, or halts the screen of a surgeon. Not to mention voting machines, ISP's, telecoms. For me having all those stopped, when properly exploited, looks more like a very scary DoS attack vector. Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels…

First things first: Kernels panic and processes crash. If your medical equipment or telco/ISP system can't recover from that then you're in trouble anyway. Why they crash doesn't really matter in that context.

As far as voting machines go, kernel panic sounds waaay better than executing malicious code.

> Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels / systems.

IIRC heartbleed didn't allow you to execute code (it allowed you to read more memory than you should have been able to). A better example is every flash player bug ever. Would you rather that thing crashes or executes malicious code? Keep in mind that the malicious code can also shut down your system.

Also keep in mind that we're talking about userspace programs right now. This thread is about kernel bugs. Userspace programs already have the option to ask the kernel to kill them if they misbehave. A lot of them do that (using features like seccomp filter) and many more should. (Chrome and Firefox both use seccomp filter I think.)

Re: Linus Torvalds: “Do No Harm”

#72

Post by Slavius »

jhasse wrote: post #67
Slavius wrote: post #57

Earlier quoted context omitted.

So what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesystem buffers or corrupting my stack pointer... Other than that browser are multi-thread/process applications. Usually only a single tab or a plugin crashes unless core browser process is affected. Most users would accept the trade off between crashed browser a…

> or corrupting my stack pointer... in that case, it will crash with a SIGSEGV sooner or later anyway

...or is being remotely exploited and it silently succeeds. Who wants that?

Re: Linus Torvalds: “Do No Harm”

#73

Post by mpe »

zx2c4 wrote: post #63

I wrote the email that prompted this quite civil response. I'm very pleased with the outcome, because I think this clear statement of his position is a lot more useful for people to work with, rather than just assuming Linus hates security or something. I interpreted his response in practical terms as essentially being the following. Patch set merge 1 has "report" as default and "kill" as a non-default option. Patch…

Depending on the bug class there may be users who never want "kill" to be the default option.

Re: Linus Torvalds: “Do No Harm”

#74

Post by mythz »

Slavius wrote: post #57
mjw1007 wrote: post #47

Earlier quoted context omitted.

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

So what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesystem buffers or corrupting my stack pointer... Other than that browser are multi-thread/process applications. Usually only a single tab or a plugin crashes unless core browser process is affected. Most users would accept the trade off between crashed browser a…

> Most users would accept the trade off between crashed browser and infected/corrupted system.

Most users are using computing devices a means of getting stuff done. They don't want to spend any energy thinking about how their software works, they want their devices to be invisible, which they use to run their Apps uninterrupted. The trade-off is whether to let Apps continue running vs hard crashing and taking down all the work they've done and all the mental energy and focus invested up to that point. If their Apps frequently crash most users aren't thinking, well I'm super glad the hours I spent on this paper I'm working on is now lost, the phone calls to my loved ones or movie I'm watching are abruptly terminated because someone's policy on hard crashing when a bug is found has been triggered. Their preferences and purchasing power are going to go towards non user-hostile devices they perceive provide the best experience for using their preferred Apps without any need for pre-requisite knowledge of OS internals.

There's not a single computing device that frequently crashes as a result of security hardening that will be able to retain any meaningful marketshare. Users are never going tolerate anything that requires extraneous effort on their part into researching and manually applying what needs to be done to get their device running without crashing.

Re: Linus Torvalds: “Do No Harm”

#75

Post by hutzlibu »

john61 wrote: post #62
muppetman wrote: post #18

Earlier quoted context omitted.

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…

I want both. Panic in a test/development kernel, do not panic in a production environment.

Well, only that most devices never were tested over months in development kernel ... and it is not possible to do so, with all those million different devices around.

Re: Linus Torvalds: “Do No Harm”

#76

Post by jhasse »

Slavius wrote: post #72
jhasse wrote: post #67

Earlier quoted context omitted.

> or corrupting my stack pointer... in that case, it will crash with a SIGSEGV sooner or later anyway

...or is being remotely exploited and it silently succeeds. Who wants that?

That is very unlikely. Crashing would happen 100% of the time though. Most people want that trade-off (meaning: If their browser would crash, they would switch to another one, even it was less secure).

Re: Linus Torvalds: “Do No Harm”

#77

Post by exikyut »

drinchev wrote: post #34
amelius wrote: 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?

Linux is used in so many critical systems. What happens when a security bug stops the ventilating machine of a person lying in hospital bed, or halts the screen of a surgeon. Not to mention voting machines, ISP's, telecoms. For me having all those stopped, when properly exploited, looks more like a very scary DoS attack vector. Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels…

Hooold it. Some of those things are not like the others.

--

I pity the engineers working on ventilation machines and the like. Medical devices are insanely hard to get right; that's neck and neck with aviation testing. I'm reminded of SQLite3's "aviation-grade" TH3 testsuite, which apparently has 100% code coverage. Let's be honest; Linux's monolithic design can't really attain that.

I would never use Linux for a medical device. I say this as someone who just happens to only be running Linux on every machine in the house right now (and I have for years, it's just how things have worked out, it's not at all novel or whatever, my point is that I'm totally comfortable with it). I'd use L4 or something instead. In a pinch I'd use a commercial kernel with tons of testing. Maybe I'd even use Minix; I'm quite sure a lot of people in industry are seriously looking at it now Intel have pretty much unofficially greenlit it as a good kernel (lmao).

--

Voting machines, on the other hand; I'd totally use Linux for that, because the security/usage model is worlds apart. Here, I WOULD ABSOLUTELY LIKE FOR THE TINIEST GLITCH TO CRASH THE MACHINE, because that glitch could be malware trying to get in.

The user experience of a voting machine is such that you walk up to it, identify yourself, and push a button. Worst case scenario in this situation is that you do some involved process to ID yourself and then the unit locks up, so you have to redo the ID effort on another unit. That is, for all use cases, not going to be a problem.

(I think that's the first time I've used all caps in years!)

--

Telecom systems... those are also a totally different world. See also: Erlang. In this situation you would likely want a vulnerability to literally sound a klaxon on a wall, but have the system still keep going.

I'm reminded here of an incident where a country's national 3G system was compromised (not the US, somewhere else) by hackers and the firmware of the backend systems was hot-patched (think replacing running binary code - the OS allowed it, it was REALLY hard to even notice this was happening) to exfiltrate SMS messages and cause calls to certain numbers to generate a shadow call (which ignored mic input) to an attacker-controlled number as well.

Telecoms is a classic case of massive scale; nowadays a single telecom switch might be routing thousands of calls through at a time. Yeah you don't want even a single machine to go down. But you DO want VERY thorough debugging, auditing and metrics.

(Which apparently don't exist.)

--

As for a Heartbleed-esque catastrophe, apparently one is going to be announced for Intel ME at the upcoming Blackhat(?) conference in December. I can't wait to hear about it myself.

Re: Linus Torvalds: “Do No Harm”

#78

Post by hutzlibu »

drinchev wrote: post #34
amelius wrote: 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?

Linux is used in so many critical systems. What happens when a security bug stops the ventilating machine of a person lying in hospital bed, or halts the screen of a surgeon. Not to mention voting machines, ISP's, telecoms. For me having all those stopped, when properly exploited, looks more like a very scary DoS attack vector. Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels…

"Linux is used in so many critical systems"

It is? I learned that in those areas you use different, much simpler and therefore more stable operating systems.

Re: Linus Torvalds: “Do No Harm”

#79

Post by dullgiulio »

drinchev wrote: post #34
amelius wrote: 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?

Linux is used in so many critical systems. What happens when a security bug stops the ventilating machine of a person lying in hospital bed, or halts the screen of a surgeon. Not to mention voting machines, ISP's, telecoms. For me having all those stopped, when properly exploited, looks more like a very scary DoS attack vector. Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels…

Thank you for that!

Seems like so many in security fail to see the DoS implication.

There is no solution to bugs other than fixing them. And that's what Torvalds and others have been saying: for a security researcher, finding the bug is the end of the job. For developers, that's just the start.

Re: Linus Torvalds: “Do No Harm”

#80

Post by extrapickles »

watwut wrote: post #51
lima wrote: post #13

Earlier quoted context omitted.

That's not a fair (or useful) assessment. Obviously, the narrow-minded security people you describe exist, but they're a minority. Many security people are developers who specialized in security, and are very much capable of building software. The kernel code is question is exactly what you ask for - instead of finding and fixing single bugs, it's a mitigation that prevents all occurrences of a particular class of bu…

When I was looking to learn about how to systematically make secure software, I did not found all that great actionable information. There is a lot about particular hacks and vulnerabilities, lists of popular vulnerabilities categories etc. There are was one book dealing with architecture and such I found. Development quite clearly is not focus of security research. A lot of advice, especially that found on blogs, wa…

As a infosec guy who was a software developer, its non-trivial to write actionable general security advice.

There is an entire academic field of study on making network related security blunders hard (lang-sec). It generally boils down to do all your parsing in one spot and a small set of features are evil.

What is really needed is a site where one can pick a bunch of features that your software project has/wants and then it gives semi-tailored advice on what to do, what to watch out for, or that you need to rethink things (eg: rolling your own TLS implementation=world of hurt).

Post reply on HN