[Secure-testing-commits] r5280 - doc

[SALVETTI Djoumé]

Author: djoume-guest
Date: 2007-01-16 23:27:40 +0100 (Tue, 16 Jan 2007)
New Revision: 5280

Modified:
   doc/narrative_introduction
Log:
Removed the reference to NVD scoring and add some details about how to set the
severity (from what have been said on the mailing list).



Modified: doc/narrative_introduction
===================================================================
--- doc/narrative_introduction	2007-01-16 22:24:21 UTC (rev 5279)
+++ doc/narrative_introduction	2007-01-16 22:27:40 UTC (rev 5280)
@@ -203,22 +203,47 @@
 ---------------
 These levels are mostly used to prioritize the order in which security
 problems are resolved. Anyway, we have a rough overview on how you should
-assess these levels. These are generally based on the 'score' from NVD
-(http://nvd.nist.gov/nvd.cfm?cvename=CVE-nnnn-nnnn)
+assess these levels. 
 
 unimportant: This problem does not affect the Debian binary package, e.g.
-             a vulnerable source file, which is not built or a vulnerable file
-             in doc/foo/examples/
+             a vulnerable source file, which is not built, a vulnerable file
+	     in doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't
+	     matter on Debian).
+	     All "non-issues in practice" fall also into this category, like
+	     issues only "exploitable" if the code in question is setuid root,
+	     exploits which only work if someone already has administrative
+	     privileges or similar.
+
 low        : A security problem, which has only mild security implications
              and one would even be comfortable with if it continues to
-             be present
-medium     : A typical, exploitable security problem.
+             be present (local DoS, /tmp file races and so on).
+
+medium     : For anything which permits code execution after user interaction.
+	     Local privilege escalation vulnerabilities are in this category as
+	     well, or remote privilege escalation if it's constrained to the
+	     application (i.e. no shell access to the underlying system, such
+	     as simple cross-site scripting). Most remote DoS vulnerabilities
+	     fall into this category, too.
+
 high       : A typical, exploitable security problem, which you'll really
              like to fix or at least implement a workaround. This could
              be because the vulnerable code is very broadly used, because
              an exploit is in the wild or because the attack vector is
-             very wide.
+             very wide. 
+	     Should be put into that category anything that permits an attacker
+	     to execute arbitrary code on the vulnerable system (with or
+	     without root privileges) and high-impact denial-of-service bugs
+	     (for instance, an IPv4 forwarding path vulnerability which
+	     requires only very few packets to exploit).
+	     Significant defects in security software can be rated "high" as
+	     well (for instance, a vulnerability in a piece of cryptographic
+	     software which flags forged digital signatures as genuine).
 
+
+Certain packages may get higher or lower rating than usual, based on
+their importance.
+
+
 NOTE and TODO entries
 ---------------------
 There are many instances where more work has to be done to determine