* Steffen Joeris [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
signature.asc
Description: Digital signature
