Xen project Mailing List

Just wanted to throw my hat in the ring as a willing volunteer, even though I
recognize we have yet settle on a process for officially volunteering.

To get it out of the way immediately: I am entirely content to forfeit any sort
of 'discoverer' privileges. In this respect, I care much more about the
integrity of Xen and its components than I do about some sort of temporary
notoriety. Similarly, I will readily sign a non-disclosure agreement, should one
be required.

Despite being involved with Xen in some capacity for a long time, my full time
work is purely in the security domain, employed by a large public university in
its security office. In addition to incident response and risk/vulnerability
assessment, code audits are a major aspect of my efforts, at the university and
beyond. The requirements, philosophies, and general procedures of similar
undertakings are part of my daily responsibilities.

If I were to become involved with a Xen code audit process, I would be
comfortable classifying issues by scope, severity, and relative risk, as well
as proposing fixes as appropriate. From a development perspective, I am
familiar with a variety of Xen components, including the low level toolstack
and hypervisor itself. Most recently, I have been focused upon
mem_access/mem_events and experimenting with using clang/LLVM at
build time.

Motivation for volunteering is simple: In my private work, I build software and
infrastructure intended to inspect and ensure the sanctity of valuable systems,
including tools for reverse engineering, and a framework for virtual machine
memory analysis. To do so, I utilize very particular features of Xen and depend
heavily upon its integrity as a matter of course. A variety static analysis tools,
fuzzers, etc., are regularly used in dual pursuit of solid development and
remediation of vulnerabilities and weaknesses. My needs therefore overlap
strongly with those needs and expectations of the Xen community.

Steve

On Mon, Sep 2, 2013 at 5:57 AM, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:

Seems to me that it would make sense to condense the discussion into a concrete proposal for review and voting. Although I am not sure that all questions raised in this thread, in particular those related to "can we mark issues related to security and create a published Coverity report that excludes security risks". From what I can see, reports are only visible via https://scan.coverity.com and accessible to project members. On the other hand, we can probably get started without resolving this. I did see mentions of risk classification, but have not been able to find a publicly manual. Also, I found references (and examples) of overview reports that we could decide to publish as part of the release cycle (or at a fixed time period), if this is an advantage to the project.

> Do coverity impose any restrictions on the reporting of issues they have
> found, in terms of using responsible disclosure etc?

See https://scan.coverity.com/faq "Who can have access?" - but the short answer is Yes, "Our [Coverity's] approach is that of Responsible Disclosure." ... "Since projects that do not resolve their outstanding defects are leaving their users exposed to the consequences of those flaws, Coverity will work to encourage a project to resolve all of their defects. Coverity may set a deadline for the publication of all the analysis results for a project." ... not clear what this means in practice though. Coverity creates an annual report, see http://wpcme.coverity.com/wp-content/uploads/2012-Coverity-Scan-Report.pdf for last year's. This includes detailed reports for some projects. Note that Linux is part of that report and that KVM's defect density is listed as 1.54 (well above Linux average).

http://www.phoronix.com/scan.php?page=news_item&px=MTI0MDA

There is also the following note, http://en.wikipedia.org/wiki/Open-source_software_security#Coverity_scan. by which projects get classified into rungs depending on their coverity usage. The FAQ does not mention these, but the above scan report refers to a target level.

There are a few other things to note and consider, from the FAQ (everybody interested in this thread should read it)
#1: "Access to the detailed analysis results for most projects is granted only to members of the open source project, to ensure that potential security defects may be resolved before the general public sees them." (section "Who Can have access?")

#2a: "Project members signing up are required to accept a click-through license." (section "Does the project or do project members have to sign an NDA (Non-disclosure agreement)?")

#2b: "You will be granted access subject to approval by project owner or Scan administrator." (section "how do I get an account?")

In other words, there are to gates and mechanism from Coverities perspective: signing the license/service agreement online and approval by scan administrator (currently Konrad). Just something to consider when we define our process.

Lars

On Sat, Aug 31, 2013 at 10:50 PM, Matt Wilson <msw@xxxxxxxxx> wrote:

On Sat, Aug 31, 2013 at 10:36:40AM +0100, Ian Campbell wrote:
> On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:

[...]

> > But I am not sure who should have the power to veto/accept
> > volunteers? Should security@xxxxxxx do that? Or should folks
> > at Xen Devel mailing list be involved in it as well?
>
> I'd be happier if this was done publicly. Since there is no security
> sensitive information at this point there is no reason for it to be
> private AFAICT. Maybe the social awkwardness of having people be
> publicly turned down is important though?

+1

The "discuss in public" approach seems to work for the "distros"
mailing list. Membership requests are discussed in the public on the
"oss-security" mailing list. [1]

> Wherever they are made I think we need requests to include a short bio
> of the person, covering who they are, what their security background is
> and why they are interested specifically in the xen project, etc. To aid
> us in making a decision as to whether we should trust them.
>
> The request should be signed with a PGP key that is part of the WoT
> strong set (i.e. reachable from mine and your keys ).
>
> We could just go with a rule that people need to already be known to the
> Xen community (e.g. have submitted a/some patch(es)), but I think there
> are plenty of security researchers out there who wouldn't otherwise work
> on Xen but might be valuable in this context.

This all sounds reasonable to me.

--msw

[1] http://oss-security.openwall.org/wiki/mailing-lists/distros

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

Re: [Xen-devel] Coverity + XenProject + Process?