Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 11 Nov 2015, at 11:36, Chris Laprise <tasket@xxxxxxxxxxxxxxx> wrote:
> 
> Hello...
> 
> On 11/10/2015 05:52 AM, Lars Kurth wrote:
>> Hi everyone,
>> 
>> firstly I wanted to thank everyone for raising this issue. I wanted to point 
>> out that we are not talking about a security process here, but the 
>> development process. Or more accurately the cost of writing more secure code 
>> and the relative importance of security compared to features. And of course 
>> the recent increase of relative importance of "built-in security as a 
>> feature" since Snowden.
>> 
>>> On 9 Nov 2015, at 16:31, Franz <169101@xxxxxxxxx<mailto:169101@xxxxxxxxx>> 
>>> wrote:
>>> 
>>>    (Please note that all of the above are my personal views, i.e. I'm
>>>    explicitly not speaking on behalf of the project.)
>>> 
>>> 
>>> It seems positions are antithetic with no possible compromise in view. 
>>> Sadly this is a general problem of FOSS software: developers tend to do 
>>> what they like and not what users request. And who can blame developers for 
>>> that? After all they are working as volunteers so they deserve to do what 
>>> they like. No possible compromise.
>> 
>> I don't think this is a fair statement: more than 95% of developers working 
>> on Xen are employees of large organisations. And they follow the priorities 
>> that their employers set. The same is true in Linux and for comparable 
>> projects and of course for proprietary software developers. Blaming open 
>> source developers, is simply wrong and not constructive.
> 
> Nevertheless, Xen is a creature of interfaces that purport to uphold 
> contracts. These (software engineering, not legal) contracts are explicitly 
> security-themed... the software is promising to isolate processes from each 
> other and protect against privilege escalation. The Xen project itself 
> asserts that it is focused on the security benefits of the hypervisor (to the 
> point of invoking "microkernel" in Xen's description), not mere 
> administrative convenience.

All of this is true from an architectural viewpoint and I don't think that has 
been disputed. And it also related to how we handle security issues, which we 
have proven to handle more effectively than most other projects and even 
commercial vendors.

> What seems to be missing from the defense of Xen project so far in this 
> thread is a level of acknowledgement of this very important aspect of 
> twenty-first century software development: Can you honor what your interfaces 
> communicate to your audience? Its true that some FOSS projects do not care 
> for modern methodologies (which are greatly about concept and mindset), but 
> should Xen be that way?

There has been some discussion around this in the past. The problem is that the 
cost of doing this retrospectively (at least in the context of certification, 
which would be one way to achieve this) is prohibitively expensive. And the 
cost of doing this for new code, is also very high. You can find some cost 
calculations in: 
http://www.xenproject.org/presentations-and-videos/video/xpds14v-certification.html

You seem to be arguing that Xen Project should be like a security hardened 
Linux distro. The project never claimed that this was the case. Moving towards 
something better, may be achievable through some better working practice. But 
not without significant investment, which will affect other members of the 
community. 

The fundamental questions is, whether for the majority of Xen users, what we do 
today is good enough or not. And whether we do better than competing projects 
and products. And I believe that compared to others we are doing better. Maybe 
the solution is for some of the security conscious vendors and users of Xen to 
collaborate and create a security hardened version of Xen, or to work with the 
community in other ways, rather than to ask others to pay them a free lunch.

> Should Xen project also be a blanket absolution of "blame"? And is the 
> corporate status of some of its contributors a proper justification for being 
> blame-less (perhaps we can think of them like members of 'The Borg')? I think 
> not.

That was not what I argued against: what I argued against the statement that 
"this is a general problem of FOSS software: developers tend to do what they 
like and not what users request". Of course vendors who contribute to open 
source do so primarily because their customers are asking for features and 
other functionality. And IMHO, the pressure to constantly deliver new things 
has actually become worse in the last 2 years. You just need to look at the 
Container and Docker hype, to see the majority of the industry appear to value 
features and the latest "shiny new thing" a lot more than security (or slower 
development velocity as a consequence of security).

> This is the trap that FOSS projects most commonly fall into: 'We are free to 
> publish because of liberty, but you are not free to criticize.' Its odd when 
> you think about it. This is the squandering of user motivation and valuable 
> feedback.
> 
> 
>> 
>> In fact, throughout 2014 and 2015, the project has received complaints from 
>> several large vendors that the Xen Project today is too rigorous with code 
>> reviews compared to Linux, KVM...
> 
> 
> Famous last words before a Heartbleed-scale media circus ensues?

This is already happening: see 
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/

>> I can certainly raise this suggestion with the Advisory Board and see 
>> whether we can make some funds available. However, the board has already 
>> invested nearly 50% of its entire budget in Test Infrastructure and is 
>> planning to continue to spend in this area at roughly this proportion of the 
>> projects budget. However, we do not have huge amounts of funds: thus, what 
>> we could do with bounties would necessarily be limited.
>> 
>> I personally also looked at other ways to change the cost-benefit equation. 
>> One example is the Feature Maturity Lifecycle (see 
>> http://lists.xen.org/archives/html/xen-devel/2015-11/msg00609.html & 
>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html) 
>> which aims to use better classification to change behaviour of contributors.
>> 
>> I do hope, that this discussion can remain constructive. De-motivating the 
>> good work many of our developers (and in particular code reviewers) are 
>> doing, is really not helpful in this context.
>> 
> 
> It does seem to me that the suggestion of a Long-Term Support (LTS) release 
> is a constructive one, among the other suggestions that Joanna made. The FML 
> you cite is interesting, but seems to be aimed squarely at developers. You 
> are bound to get better results if the expectations of users change along 
> with developers, so LTS releases may be the better idea.

The FML is clearly targeted at developers - actually more at vendors who 
contribute to the project. 

As for a LTS release, I assume what you meant is to allow security conscious 
people to have a long-term baseline of Xen, which does not include new 
features. We do have mechanisms for this in the community today: any vendor, 
individual or group of vendors are very welcome to own and maintain such a LTS 
release with support and backing from the project. In fact, this is not that 
hard and does not require that much effort. And I would also be willing to 
support such a proposal if some people stepped up and see whether more 
interested parties can be pulled in. To create a security hardened LTS branch 
however - which it seems you and others are arguing for - would of course be 
significantly more expensive. 

That is not to say that we are unwilling to improve: I believe the project has 
a track record of improving working practices. But in the end trade-offs have 
to be made somewhere. And a realistic compromise will most likely fall short of 
a security hardened Xen LTS.   

I don't think it is acceptable though to ask others to foot the bill for it, 
without contributing something. In particular if what we do today is good 
enough for those who put the effort in. That approach very much feels like 
"getting a free lunch and complaining that it isn't what you were hoping for".

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