* Steffen Joeris <steffen.joeris@skolelinux.de> [2009-03-18 18:48-0400]: > On Thu, 19 Mar 2009 09:19:28 am Micah Anderson wrote: [snip: removed some unrelated stuff to move discussion to debian-security, please reply there] > > On a somewhat tangential note, I've been asked a number of times by > > people why Debian doesn't have security review/auditing of core > > important packages. These questions have come more frequently after the > > openssl issue happened (which for some reason people tend to call a > > 'debacle', why that word was chosen and repeated would be an interesting > > research project). > > > > In OpenBSD they have taken their security audit team (between 6-12 > > members) and set them on looking for security holes through a process of > > file-by-file analysis of their critical software components. They > > determined which elements of the core system are the most critical and > > have spent a lot of time on reviewing these pieces. This is a process > > whereby code gets audited and re-audited by different people with > > different skills over time. Debian has an audit team, but its more of a > > side-project than a commitment by the project. > > > > The OpenBSD security auditing process has succeeded because it was > > proactive in this approach. I think that the auditing process is not > > trivial, but it does seem like it would be a good thing for Debian to > > tighten up in this area. I dont know what packages this would mean, or > > what this process would entail, but I know we have a team of folks who > > are commited to auditing in Debian and we just need to bring them closer > > to the core in some way, without making those core maintainers feel like > > their work is under suspicion. > > Not really sure about that one. > However, what tends to happen a lot is that fairly new packages are full of > security issues. Quite often it is the case that one flaw is detected by > chance and then a further audit reveals all sorts of funny things (this just > so happens to be the case with a lot of PHP/web stuff). It is impossible to > detect all these packages before the release and it should also be a last > resort to remove such packages from a stable release. The point I was making was about a small subset of "core" packages, not the entire archive. I think the entire archive would only ever be done through an automated scanner. Perhaps the subset would be 'essential' plus one or two others that introduce vectors into a system, but which are necessary to access a system and are not 'essential', such as openssh-server. If the set was small enough then in-depth analysis could be done, and on a regular basis. Focusing the efforts of some skilled security auditors on some core Linux programs (even openssh) would benefit more than just Debian as well. However, I do see your point about NEW packages, and it might be interesting, if we could get enough security auditors who had the skills and the time, to be a part of the NEW process. This could introduce an unnecessary delay in the processing of packages, depending on the depth and bredth of such an audit. Or even or a false sense of security if people think that their packages are free of security holes if they've passed NEW. > Maybe more people could join the debian security audit team? For a lot > of PHP packages it would be enough to check whether certain functions > (e.g. htmlspecialchars) are found. If not, this is often an > indication of insufficient protection measures. Calling all interested security people who have just been dying to show their skills, or develop stronger auditing skills! micah
Attachment:
signature.asc
Description: Digital signature