|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Publicity] Docker Open Source Container Virtualization on the Rise
>@Russell, maybe you can add a couple of slides to the security talk I will definitely give it a shot when I get back home. On Thu, Feb 13, 2014 at 12:58 AM, Lars Kurth <lars.kurth@xxxxxxx> wrote: > Hi all, > thanks for the contributions. This is very valuable. > https://lwn.net/Articles/524952/ is well worth a read! Thank you Tzach > @Sarah, is this enough? > @Russell, maybe you can add a couple of slides to the security talk > Lars > > > On 12/02/2014 13:55, Anil Madhavapeddy wrote: >> >> On 12 Feb 2014, at 08:44, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: >> >>> On Tue, 2014-02-11 at 19:42 +0000, Anil Madhavapeddy wrote: >>>> >>>> Perhaps the simplest thing is to look for a list of recent CVE >>>> vulnerabilities and highlight which ones would be blocked by Xen, KVM >>>> and containers. >>> >>> One thing worth remembering is that while Xen has a well defined >>> security response process[0] and is proactive and transparent about >>> issuing advisories (and CVEs) for anything which we become aware of, >>> even relatively minor issues, while I don't believe the same can be said >>> of Linux and by extension containers. >>> >>> AFAIK security fixes to Linux are made, deliberately and explicitly, in >>> a very low key way and appear as any other bugfix. They are not >>> highlighted as security relevant and mention of a CVE or security aspect >>> is routinely stripped from the commit log comments. CVEs are issued >>> after the fact, if at all, when someone who is watching the commit >>> stream spots it, realises the security impact, and requests it for >>> themselves/their distro/etc or when the original author does so >>> independently. >>> >>> So the risk is that Xen CVEs will be over represented in the set of >>> CVEs. On the other hand maybe the sheer volume of CVEs means that even >>> if they are under reported there are loads of them anyway... >> >> I think that's an excellent point. The flipside is to look at exploit >> sets instead, which are basically independent of security processes. >> >> A quick look at Metasploit shows this collection: >> https://github.com/rapid7/metasploit-framework/tree/master/modules >> >> ...which sadly (?) doesn't include Xen or KVM, or any other hypervisors, >> but I'm sure there must be a similar set elsewhere. >> >> -anil >> >> _______________________________________________ >> Publicity mailing list >> Publicity@xxxxxxxxxxxxxxxxxxxx >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |