[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1103041200201.3265@faron.mitre.org>
Date: Fri, 4 Mar 2011 12:05:02 -0500 (EST)
From: "Steven M. Christey" <coley@...-smtp.mitre.org>
To: Solar Designer <solar@...nwall.com>
cc: Florian Zumbiehl <florz@...rz.de>, oss-security@...ts.openwall.com,
"Steven M. Christey" <coley@...-smtp.mitre.org>,
Stefan Fritsch <sf@...itsch.de>, Jan Kaluza <jkaluza@...hat.com>,
Paul Martin <pm@...ian.org>, Petr Uzel <petr.uzel@...e.cz>,
Thomas Biege <thomas@...e.de>, Jan Lieskovsky <jlieskov@...hat.com>
Subject: Re: CVE Request -- logrotate -- nine issues
If there's a common usage scenario that doesn't stem from blatant
administrator negligence, then a CVE is probably still appropriate.
("blatant admin negligence" might be, say, if an admin arbitrarily makes a
script setuid, or modifies the perms for an executable or config file to
be world-writable.)
We will sometimes write the CVE description more as an "adminisrator
practice" than as "fault of the software."
For example, default passwords are fair game; arguably, if the admin
didn't read page 24 of the documentation that said "change the default
password," this is more the admin's fault than the software's fault... BUT
the issue has to be dealt with, either way, so a CVE becomes a "signal"
for that action to take place, whether it came from the software or from
the user.
Not everything is that clean and straightforward of course, but that's the
general thinking.
- Steve
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
