On Wed, Oct 06, 2004 at 09:42:30AM -0700, Thomas Bushnell BSG wrote:
> I'm not saying we must do it at all.  I'm saying that security is the
> responsibility of the security team, and not debian-devel.  Having not
> heard from the security team what they think, and this apparent
> reluctance to actually ask them and carry on the discussion with thim,
> means that it will probably never get addressed.

I think you are misunderstanding what the security team in Debian does. The 
Security Team in Debian has a very large, often not recognised job of 
producing _security_fixes_ for software in the stable archive which has 
been found vulnerable to a given attack or exploitation attempt. That is, 
they fix a very specific type of bugs (security bugs) in a very specific 
archive (stable).

They have not taken the task on them to:

a) provide new security software in the archive, be it IDS, AV engines, 
vulnerability scanners, hardening software, or new protection systems 
(SElinux, PaX, exec-on-shield, SPP...), etc.

b) provide updates to the knowledge base that empowers some of the software
above (mainly IDS, AV engines and vulnerability scanners)

c) do a security audit of all the software in Debian to detect unknown 
vulnerabilities

You could call of this "security" but that wouldn't mean that it's the
security team's job to do it. Willing DDs are already doing some of these
tasks and providing their work for the benefit of the Debian community. 
Discussion on how to do b) properly, for example, is something that should
be left to -devel for discuss and to maintainers to implement as they see
fit (with the approval of ftp-masters, if necessary)

As for me, I'm currently maintainer for both Nessus and Snort. Both can be
considered the best free software available in Debian GNU/Linux to do
vulnerability assessment and intrusion detection. I rather have mechanisms 
in place well tested and able to allow administrators to update the 
"knowledge base" (call it new plugins or new rules depending on the 
software) as they see fit picking it up directly from upstream. Any of 
these programs should be able to handle these updates in a clean way without 
breaking [1].

I'm not considering providing new package updates for these engines _even_
if a new feature comes up that helps them do the job better or in new ways
[2]. A new feature should always go through the
experimental->unstable->testing->stable process and new items in the
knowledge bases that depend on it should be removed from the one provided
upstream for the stable release. IMHO this is true even for virus scanners,
if a new engine is written that does things better than the previous one
did, that is _not_ a security fix, even if new virii cannot be detected
unless you use this new feature.

If you feel AV scanners, IDS and similar software is not as up-to-date as 
it should be then, by all means, help making release cycles shorter [3] so 
that no backports are really necessary for these and other software. Trying 
to fix a problem (release cycles in Debian) with a new feature 
(volatile.debian.org) is not really going to work IMHO.

Regards


Javier


[1] That brings to mind, for example, 
http://lists.debian.org/debian-devel/2003/08/msg02258.html
and I have yet to see Snort upstream taking action on this issue (maybe the 
discussion went unnoticed)

[2] The new "scan through SSH with shared secrets" feature available in 
Nessus comes to mind.

[3] Maybe even predicatble and less than two years.

Attachment: signature.asc
Description: Digital signature

Reply via email to