Date: Wed, 26 Sep 2012 09:35:15 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: Re: Re: Re: CVE request(?): gpg: improper file permssions set when en/de-crypting files -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 24 September 2012 22:03:20 Steven M. Christey wrote: > FYI, this discussion is an interesting example of what I've called the > "snowball effect" in CVE when new kinds of issues arise that test the > boundaries of what should or should not belong in CVE - allowing one (or a > handful) could open the door to hundreds or thousands of other products > that have the same issue. I think it might make sense to look at this issue along the lines of RFC rfc2119 and sort the problems out a bit. Classification of program output sensitivity, on a sliding scale: MUST - GPG private key, OpenSSH private key, OpenSSL private keys, some log files for server apps, etc. [MUST - where having the file revealed would grossly impact security/negate the whole point of the operation/program or where there is a significant chance of sensitive data being output in the normal course of operations, for examples servers running in debug mode that log credentials in the log file] SHOULD - Generic output from crypto programs/etc. health/finance apps [SHOULD - potentially sensitive data such as encrypted content, health and finance data, other regulated output, chat logs, etc. Things that would typically contain potentially sensitive data in output] MAY - Generic output from things like tar/archivers, editors, etc. [MAY - none or extremely minimal negative impact, performance wise/etc, for example a file down loader] SHOULD NOT - nothing comes to mind [SHOULD NOT - where securing the output has a negative impact] MUST NOT - nothing comes to mind [MUST NOT - where securing the output would have a significant negative impact] OPTIONAL - catch all for weirdness RECOMMENDED - anything can have one more more recommended Basically stick programs into this framework with evidence/reasoning as to why they fit there, please note that a program may fit into one or more categories, e.g. some output (like key creation) falls under MUST and some (like encrypted messages) fall under SHOULD (this is an example, I'm not saying encrypted messages are a "SHOULD" and not a "MUST", I just needed an example). So at least this way we bring some sanity/order to the problem rather than this general mishmash of "well it should" and so on. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQYyCzAAoJEBYNRVNeJnmTpRUQANs61iVcz+QJlsFMkH8brptV wIeJqKGRMlwAvcUM32ydj74F3ScNi4sZ6zy+UDLL3TS3m+BxMxGLhbBmJJh6rBWF LkhTarTYNhcbTdmrLNT4NqOgmVsFo4LShGD0V3uMFuQa01kGsW4VFBSwwfx0RaS2 2g3hJ/JzJM92iO1fha281v6wdd79mRdRz69O/gQQlYbN8X0AIBDN9Kpd9M8bQJee ZGaoCpa0xh0GV0Ur+9ikR9OY+M619Fvnc/grV1ydL06A1MbLNMOxmo7fM2J4Zu/g sNm7364hoJdEso9QQg/OHPkDrzex8X6RIcz0UeMk/9/rbCMRvnE45crMjjpzdtnd Zcmpa1IvOToQKPu+LzqQ0p7Vqv7+/io9kb5DJJd0WaOQ5zPKddkIefHO+JgykW0R QdT0/H/RV49TDUs4w189WIdM98Hdeaf8KSnV4LEnjdPoYtM1I0pTQeAKEtlfWBhq eqTPze6ohZGm/VEHuX5HugcPY+a3oppr1UrVv4xiwGP7FPNoWCjAkzi63/RpunvP MusAI+9FBOHJO4hTcgamEng/C+wHvSIi3eVecTfCtEFAE4V8bhmJ4IVtvi3mIYG4 6mWnTRIxy7Hxv/sguHTP+UKS/PREeqxn9vaGQ/JX7tNqj3a4RPiD+XFFfIdtxC7c lsE7kyw3NvTIVovVbZR6 =QJk5 -----END PGP SIGNATURE-----
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.