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.
signature.asc
Description: Digital signature
