This one time, at band camp, Thomas Bushnell BSG said: > Stephen Gran <sgran@debian.org> writes: > > > I thought that 'issues related to the development of debian' was on topic > > for this list. It is not at all clear to me that this is a security > > issue, because outdated A/V software usually does not place the server > > it runs on at risk for compromise. > > We have been told that: > > 1) Outdated A/V software must be upgraded, because the upgrading is > critical to the security of the machine that relies on it. Yes, but see below for the problem. > 2) If it is not upgraded, then it is better not to have it at all. > > Both of those seem to be true to me of, say: > > A) Outdated ssh binaries must be ugraded, because the upgrading is > critical to the security of the machine that relies on them. An outdated ssh may allow access to the machine that has sshd running on it. The same is not true of a machine running clam (in the case of this particular general discussion - if a compromise was found in clam itself, that would be grounds for a security upgrade). Clam protects (largely windows) clients behind it, and not, generally speaking, the machine that it runs on. It does not sound like this is suitable for the security folks, who are already overworked as it is. > B) If they are not upgraded, then it is better not to have them at > all. True. For the class if software I am talking about, though, it is not so much that the outdated software is a potential avenue of attack in and of itself, as it is a waste of CPU cycles and a false sense of security. > Now in the case of ssh, we have set up a special security archive to > deal with the case. > > I think (1) is true, and I think both (A) and (B) are true. I am not > sure about (2), but I do understand why people are arguing for it. If > they are correct, then it seems to me that the security archive is > already an excellent place for the updates. I think the difference is that, up to this point, the security archive has been used for fixing software that had a bug with the potential to compromise the local machine. These uploads are (AFAIK) always accompanied by a DSA, and usually have CAN advisories associated with them. The upgrades that I am talking about are a different class of upgrades, as they generally make no difference to the local machine in most cases, and there is no need for a DSA, and certainly no CAN advisory for uploads of this type. So what we have now is: 1) stable: no new code, no changes so as to be as stable to administer as possible. 2) security.d.o: only fixes that have to go in - no API or ABI changes, backport only relevant bugfixes to fix possibility of compromise What I (and it seems, others) would like to see is: 3) some other method to upgrade software that has to change rapidly to meet new classes of threats, even though these threats may not affect the machine running the software itself. This category seems to me to be composed of A/V scanners, anti-spam suites, and IDS-type software. I may be missing some, and I'm sure someone will chime in with it. The problem with not having 3) is that you end up shipping software that doesn't keep pace with the new threats in the wild. At work, we have to keep a rather large private repository of backports towards the end of a stable release to cope with this, and I'm sure many other places do the same. It seems counter productive to have people redo the same work in many places, instead of doing it right in a single place. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgp5LXNrYL9bb.pgp
Description: PGP signature