Long-lived security holes

Posted Jun 30, 2004 6:51 UTC (Wed) by koide (guest, #22687) [Link]

As has already been said, the severity of a bug can't be accurately assessed generically without extensive work. Nontheless, it would be useful for vendors to agree in a common classification of security holes, not using it to describe their severity, but for people to know how can they be triggered and what they are known to do.

Each of the categories should be clearly defined, thus allowing each admin find out how to sort the install order of the packages according to her particular configuration. Package tools could evolve to use this classification to apply the updates in an admin defined order, if there is no defined order, all updates are treated equally, just as happens now.

Even if the things posted here don't cover all possible cases or can't make clear distinctions between each of the categories, they can make a useful start for such a classification. For instance, I think the 'human local account'/'non human local account'/'without account', 'DOS'/'root compromise'/'non root compromise' and 'server'/'client'/'both' distinctions could be part of it.

I think even just a standarized distinction between vendors for the first criteria will help a lot of admins, but I can't prove it :-)

Of course, a classification for this kind of domain ends up being faceted because issues such as 'servers usually have a non human account in the machine, therefore the exploit which uses the server to gain its shell account privileges falls under two categories' often arise, but it is a manageable problem and it gives some extra flexibility when writing rules.