Open Stack

So I think two things probably need to happen here. One is a further
discussion on how 'dangerous' code should be tagged in future, the second
is if this needs a CVE.

In regard to the latter I don't think there's a big reason _NOT_ to cut a
CVE but I'm not passionate about it either way. What I would like is some
agreement so if there is a CVE I can reference it in the OSSN and if there
isn't I can just go ahead and publish.

Cheers
-Rob

On 02/07/2013 20:15, "Kurt Seifried" <kseifried at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 07/02/2013 01:06 PM, Jeremy Stanley wrote:
>> On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
>>> Huh? According to: https://wiki.openstack.org/wiki/Baremetal
>>> 
>>> "This driver was added to the Grizzly release, but it should be
>>> considered somewhat experimental at this point. See the Bugs
>>> section for information and links to the Launchpad bug
>>> listings."
>>> 
>>> also no mention of any security issues with respect to data not
>>> being wiped. Now I get that the software hasn't been officially
>>> blessed as production ready, but it has been released publicly.
>>> Unless there isa compelling reason not to assign a CVE for this
>>> (speak up now!) I'll do so later today.
>> 
>> I agree it's unfortunate if security precautions weren't spelled
>> out in the release notes, so if that qualifies for a CVE then it
>> sounds like we probably do need one. In your opinion would it have
>> needed a CVE if the situation were spelled out in the release notes
>> already?
>
>If the documentation specifically said "WARNING: DATA MAY BE EXPOSED
>DUE TO LACK OF WIPING" then no CVE most likely. It's a continuum, but
>basically some examples:
>
>=======================
>http://seclists.org/oss-sec/2013/q1/155
>
>Further note, for example:
>
>A default account/password in a device or service. Is this a security
>issue or not? Different scenarios have different outcomes:
>
>1) The default account/password is well documented. The services
>forces you to change the password when first run and will refuse to
>run until you do change the password. Generally not considered a vuln.
>
>2) The default account/password is well documented. The services does
>not force you to change the password when first run. Generally not
>considered a vuln as it falls into the "don't do stupid things" class
>of issues.
>
>3) The default account/password is not well documented or not
>documented at all but can be changed. Generally this would be
>considered a vulnerability.
>
>4) The default account/password is not well documented or not
>documented at all and can NOT be changed. Generally this would be
>considered a vulnerability.
>
>Similar things for other things, is it a security vulnerability or
>security hardening, or not a security issue at all? It definitely gets
>fuzzy/messy sometimes.
>=======================
>
>So this looks like a #4, not documented, not something that can easily
>be fixed by the user.
>
>> I suppose this drives to a process question for us as a project,
>> whether we can actually develop work-in-progress/experimental
>> features in-tree with a timed release schedule, knowing that we
>> may need to consider either (dangerously) ripping them back out at
>> release time or announcing known security vulnerabilities in them
>> at release time instead.
>
>That is a good question. One thing that might be helpful is to mark
>such code as experimental/dangerous/may eat all your datas and include
>any potential gotchas to warn people about, which is probably a good
>idea either way as it would reduce risk, or if not that at least let
>people make informed decisions about the risk they are taking.
>
>- -- 
>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.13 (GNU/Linux)
>
>iQIcBAEBAgAGBQJR0ybPAAoJEBYNRVNeJnmTMOMQAJnhG3tJ/6AoM7wptHLYT+P0
>k1RAILsNqWsK213IqL+mpnVlVMqj4NllJyokSejbfywTaFpw0kq9il4BHmr/5k9F
>BeXJLBjUicuqaylyTp+dQbKADgViIpAuw703RTO5Irumugmrqcr/Pj6a2e4JGeY9
>d6MN0plPEaiKSNUX4H/wyqthzwpfx1OIv9BHhY1geHgZUpxsLGeE0aGxGab91Vwv
>SPetHIpB9QqzV9TKFWvTDPWxFU2xU/56mEe/WOqCRdrSh29/ki3zisdCAyvM2ry/
>14pDWKFKJDY7OiKx9OnbSFeGf7mH6Si8YfAOxeQU+fe39dPMaZJNxY415pE8Zh0F
>p5RWZ7mTGkxGwemk2E11ODUKM9iKmJuWaE8pgIGEVncoJqOLiFCPU5wl97zChHeq
>Xiz//CYS7ZklMuvboxIM8knp9eHdFpiLp2h4ELDCNHv807uYNaWptRvlP1Zhyq9u
>obqLQP/V9Bb/2HSmqLbOpVsacIZp/BQY/cnjCGERwMA17psY1ggl8NT89exSjop9
>jXonYuNoe21Z5Fjh+C50hkBpREBKXTcgk2jKpX2+dSLz/M0japctKCoguc2yCGWl
>nzrNLi9l87i/d9bintdMdX/qhREwwb938xnvkfVRFc05XTqEcm+vrLLu0Y5pW76K
>G0Hh7vc2TXLY3OygOygX
>=lC0m
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security