On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow wrote: > > Probably best to just ask the release team (cc'd) for their preferred > > approach. > > Could we quantify that somewhat? Is one security bug enough? Are 10? There's no way to quantify that as security bugs are linearly dependant on lines of code [1] > Do we have a delegate that could audit and veto a package already > other than the release team? Is that the domain of QA or security? That's currently the domain of the BTS. Anyone could publish sufficient security (RC bugs) in a vulnerable package that it would make it impossible for it to be released. Of course that would only be possible if: a) the package is full of bugs b) someone did a full audit of it Unfortunately, the Security Team does not get to decide what they support security-wise. I talked with members of the Security Team about this in the past and have talked about this publicly in two Debconfs, we will get to a point where we will have to say "the Security Team only supports packages in 'standard' in the 'stable' release, other package sections are supported in a 'best effort' basis". That's not really much of an issue, mind you, it is the same security treatment provide to Fedora Core "extras" or OpenBSD, FreeBSD or NetBSD "ports". And, by the way, is more or less what is happening know since package priorities set the priorities for attention of the Security Team when they have to rush a DSA. > Maybe any new package (one not in stable already) that has a security > bug could be automatically blocked from the next stable release until > a source audit by some team (security? qa?) is done? Doing this for > every new package is probably too much to ask timewise but for any > package known to have one exploit already that seems prudent. There are different types of security bugs, some are stupid and non-consequential, others are just as stupid and have dire consequences. Not all security bugs are equal [2]. If you are going to rule out packages that someone found a security bug in, I can assure you [3] that we have a high number of packages with security bugs nobody has yet ever noticed. What would you do? Have the security (or audit) team have veto powers over all the archive? You are using an "innocent until proven guilty" line of thought, I would rather go further and imposse an have "guilty until proven innocent" line of though for packages that: a) install a tool that root will run (i.e. /sbin/ or /usr/sbin) or runs with "higher-than-user" privileges (i.e. setuid/setgid) b) installs a daemon (more so if it's a network service) or gets run at runlevel switching c) install a cron task (or other automatically-run task) d) receives data from the network (i.e. a network client) However that might mean putting a *large* number of packages on hold until someone has time to complete a security audit, and the resources of the Audit Team are scarce. Just my 2c, Javier [1] Based on empiric test published in scientific (i.e. IEEE) journals, but you know the line "lies, damn lines.." [2] CVSS helps getting them rated, however, http://www.first.org/cvss/ [3] Based on the latest run I made tring to find local security bugs (i.e. temporary race conditions) working for the Audit Team.
Attachment:
signature.asc
Description: Digital signature