KS2010: Security

The background for the session was the list of 80 CVE numbers assigned to the kernel so far this year - a list which is known to be far from complete. We are currently logging more than two vulnerabilities per week, making the kernel a leading cause of the global shortage of available CVE numbers. Even if a number of these vulnerabilities are not gravely worrisome (there are many of the "might leak eight bytes of kernel stack to user space" variety), others are full root compromise holes. Events like the Stuxnet worm have made it clear that there are groups with significant resources which are interested in compromising targeted systems; perhaps it is time for us to up our game somewhat. Your editor is clearly not alone in thinking this way.

The questions your editor had for the group in particular were:

1. Are we happy with the state of Linux security? Or do we maybe think we should be doing better?

2. Assuming we want to be doing better, what should we be doing to improve the situation?

3. How confident are we in our web of trust? Given the number of vulnerabilities in the kernel now, it seems unlikely that anybody would need to go to the trouble of deliberately injecting new ones. Even so, it would be nice to know that we are robust against such attacks.

Linus responded to the last question first. Once upon a time, he said, most pull requests came from trees which were hosted on kernel.org. That increased his confidence: he liked having a relatively small set of source trees on a well-protected system. Now increasing numbers of requests are coming for trees on public hosting services. He does not refuse to pull from such trees, but he wanted to let it be known that he does scrutinize what he finds there more closely. So far, Linus has never received a malicious pull request - that he knows about.

Somebody asked whether people pushing trees to Linus should be required to get a kernel.org account; he thought that would not improve the situation. The main comfort from kernel.org-based trees came from their relatively small number; creating more would just make things worse. Another question had to do with whether developers should have to cryptographically sign their trees. Linus thinks it would be more pain than it is worth; the key management would be no fun at all. And, he says, requiring signatures would just push the problem down one level. In the end, you need to know who to trust.

A number of developers took the position that security holes were really just a review problem. Ted Ts'o agreed, but also cautioned that a look at the results of the Underhanded C Contest were worth a look. Malicious code can look awfully innocent with enough effort.

Greg Kroah-Hartman said that security bugs are just bugs, and we've been fixing them as quickly as we find them. Linus had some strong words for "security" companies which pay people to find bugs and keep them to themselves. This activity may somehow attract customers, but it sure doesn't improve anybody's security.

There were questions about adding better defenses against specific attack patterns. Some of that has been done; many core VFS system calls have parameter checking at the VFS layer, making it hard to introduce vulnerabilities further down. Some work has just been done (after some new vulnerabilities were reported) to harden the handling of iovecs in network protocol implementations. Certainly there is more that could be done in this area. But, as Linus pointed out, many of the problems tend to be in ioctl() implementations, and there's little to be done about those at the higher levels.

Mike Rubin asked what the community's commitment to security is. He is having a hard time knowing which parts of the kernel he can rely on to be minimally secure. Linus said that the best answer is to ask how many people are using any specific bit of code. Modules with more users have had more testing and developer attention, they tend to be more secure.

Tony Luck asked about whether people are testing the kernel using fuzzing tools. Some attackers certainly are, it seems, but it's not clear that kernel developers are doing the same. Among other things, one would think that the recent 64-bit system call vulnerability, which sat undiscovered (by the good guys) for two years, should have been caught by any serious amount of fuzz testing.

By the end of the session, it seemed clear that many of the developers in the room remained mostly unconcerned about the kernel's security record. To the extent that they are concerned, they don't see what can be done beyond continuing to look at code and fix bugs as quickly as possible.

Next: Scheduler issues.