Open Stack

On Mon Jan 20 11:47:32 2014, Daniel P. Berrange wrote:
> On Mon, Jan 13, 2014 at 08:24:41AM -0800, Nathan Kinder wrote:
>> Hi,
>>
>> I have started to put together a wiki page skeleton outlining the
>> process to follow when writing a new Security Note (OSSN).  I think it's
>> far enough along to share.  Any feedback and suggestions would be
>> appreciated!  The new page is available here:
>>
>>      https://wiki.openstack.org/wiki/Security/Security_Note_Process
>
> I think it is good that you're taking steps to formalize the security
> reporting process for OpenStack. Having just done the same for libvirt
> I've got a few suggestions about the data format for recording this.
>
> The wiki describes using the email text format as the master data
> format for the OSSN, which I think is a mistake. For libvirt we
> identified that we need to have ability to report in at least 4
> different data formats - text, html, native libvirt xml and cvrf
> xml, with potentially more in the future if the security industry
> decides cvrf is no longer their best fit.
>
> To make it easy to produce data in multiple formats we decided that
> it was better to have a simple XML format as the master data format
> for our vulnerability reports. It is was then a simple matter of
> applying an XSL transform to generate the text / html / cvrf formats
> from that.
>
> An example of the master data format for a LSN is this:
>
>    http://security.libvirt.org/2014/0002.xml
>
> And corresponding auto-generated HTML + Text docs
>
>    http://security.libvirt.org/2014/0002.txt
>    http://security.libvirt.org/2014/0002.html
>
> The use of XML also lets us generate an index page of all flaws
>
>    http://security.libvirt.org/index.html
>    http://security.libvirt.org/index.xml
>
> Note that the website has clear, stable URLs for issues. We've
> not actually done the CVRF conversion yet, but will do in the
> not too distant future. In addition we're also planning to
> add URL shortcuts for CVE numbers eg so you can visit a link
> http://security.libvirt.org/CVE-2014-242.html and get redirected
> the corresponding LSN URL.
>
> On the specifics of the data to be recorded, I think the template
> in the wiki is missing a couple of pieces of important metadata.
> You should record key dates about the issue including when it
> was reported, when it was fixed and when it was made public. Note
> that those dates can be in any order wrt each other - you don't
> always get things in a tidy reported < fixed < public order. It
> is also good to credit the person(s) who reported the flaw and
> who fixed  the flaw to give recognition of their important
> contribution to the project since they may be outsiders.
>
> The affected services really should record detailed specifics of
> where the flaw was introduced and fixed in GIT for each affected
> GIT repository. You'd want this right down to the changesets and
> release tags for both cases. We've found this is important data
> to assist us in ensuring we identify what branches are vulnerable
> and what should be backported. In writing up our historical list
> of vulneribilities this highlighted a nbumber of mistakes made in
> backporting fixes to older branches.
>
> During initial handling of the vulnerability these docs are just
> discussed over email. Only once the vulnerability is public do
> they get added to a GIT repository, and announcements sent out
> to public mailing list, etc. The website is auto-generated from
> the GIT repository once an hour. I'd be wary of storing OSSNs in
> the wiki since people who view the pages would have a pretty low
> level of trust in the data, unless the pages were edit-restricted
> to solely members of the security team. Having a website whose
> content is auto-updated from GIT by a cron job gives you a high
> level of trust in the data since you know any changes to the website
> must have corresponding changes in the GIT repo, as no human manual
> steps were involved.
>
> FYI if OpenStack wants to re-use/adapt any of the scripts/templates
> we use for libvirt, then Red Hat is fine relicensing them from GPLv2+
> to the ASL-2.0 used by OpenStack projects. If the XML format described
> is suitable then you'd mostly just need to change the CSS styling to
> apply OpenStack branding to the HTML
>
>    http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary
>
> Daniel

Thanks Daniel, I think you raise some good points but perhaps you are 
blurring the lines between security notes (OSSN) and security 
advisories (OSSA) a little too much.  It's worth keeping in mind that 
we are not talking about how OpenStack handles security advisories, we 
are talking about OpenStack Security Notes that provide guidance around 
configuration and software choices that have potential security impact 
to OpenStack deployments.

( fwiw I think that OSSAs probably should be published in CVRF 1.1 )

In many cases we wont have metadata such as  'reported date,' a 'fix 
commit', or even a 'broken in' date. Often we are not talking about 
specific defects but potential bad combinations of software, bad 
configurations (user end) etc. In fact we are almost never referring 
directly to a vulnerability in the OpenStack framework with an OSSN.

We don't have the same downstream consumers of OSSNs that libvirt LSNs 
or for that matter, that OpenStack OSSA's have. We don't necessarily 
need a format that's easily machine read - OSSNs are usually very 
subjective and require the reader to make an evaluation on the impact 
to their deployment. (I suppose I can see an opportunity for some 
future project that makes use of OSSNs as part of an automated 
checklist for an OpenStack deployment, but OSSNs are so broad that 
almost every one would be liable to generate false positives.) I'm not 
completely against having a machine readable format that can be parsed 
out into various languages but I think it might be a bit over-the-top 
for what our requirements are.

Your offer to relicense the scripts etc that are used by the libvirt 
project is greatly appreciated, having tooling available significantly 
lowers the bar in terms of adopting it, I think perhaps this is 
something that we should consider discussing at the weekly security 
meeting.

Cheers
-Rob