Running a site like LWN provides a great deal of experience in making a
fool of one's self in front of crowds of knowledgeable people. So perhaps
it was natural that your editor, of all people, ended up running a session
on security at the 2010 Kernel Summit. The purpose was to share some
concerns about the security of the kernel; whether anything was achieved
remains to be seen.
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:
- Are we happy with the state of Linux security? Or do we maybe think
we should be doing better?
- Assuming we want to be doing better, what should we be doing to
improve the situation?
- 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
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.
to post comments)