[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Secure-testing-team] Re: Removing insecure packages from etch

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

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,


[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

Reply to: