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

[Goswin von Brederlow]

Javier Fernández-Sanguino Peña <jfs at computer.org> writes:

> 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:

That wasn't what I suggested (below). The BTS only stops a package
from being released due to known bugs. I ment that if a package has
such a bug that it gets still blocked from the next release even if
the bug is fixed without an audit of the code by e.g. the security
team.

This is ment to prevent one security bug after another to show up on a
weekly basis in a package in stable. I'm assuming that more people
will use it once it hits stable and then more bugs get found. Waiting
for another release also means new project have more time to mature.

> a) the package is full of bugs

The save thing to do is to assume it is full of bugs. Where there is
one there will be more, unless

> b) someone did a full audit of it

someone did this to see if it was just a fluke.

> 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.

I would rather have less packages in stable so that the security team
does have enough resources. If a package is in reasonable danger of
having security bugs then it should not get into stable.

>> 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:

More a blak&white world view. If it has at least one security bug then
it is black and must be audited.

> 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)

Some thread assessment and the kind of security bug detected should
have influence on the decision, sure.

I think any new package with your 4 cases should be audited if that can
be done. I fear though that there isn't enough manpower for that.

> 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.

Exactly. Hence only do that for suspect packages as defnied by having
(had) a known security bug.

> 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.

MfG
        Goswin