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).



git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@5280 e39458fd-73e7-0310-bf30-c45bca0a0e42

1 files changed, 32 insertions, 7 deletions

diff --git a/doc/narrative_introduction b/doc/narrative_introduction
index 7f3b77ef08..28de887b64 100644
--- a/doc/narrative_introduction
+++ b/doc/narrative_introduction
@@ -203,21 +203,46 @@ Severity levels
 ---------------
 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
 ---------------------