[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen Security Advisory 180 (CVE-2014-3672) - Unrestricted qemu logging
On Wed, May 25, 2016 at 03:51:23PM +0100, Wei Liu wrote: > On Wed, May 25, 2016 at 03:04:40PM +0100, George Dunlap wrote: > > On Mon, May 23, 2016 at 6:09 PM, Xen.org security team <security@xxxxxxx> > > wrote: > > > RESOLUTION > > > ========== > > > > > > Applying the appropriate attached patch resolves this issue. > > > > > > The patches adopt a simple and rather crude approach which is > > > effective at resolving the security issue in the context of a Xen > > > device model. They may not be appropriate for adoption upstream or in > > > other contexts. > > > > This is indeed a rather crude approach; but for our upcoming 4.7 > > release, what's the plan? Do we have time to generalize xenconsoled > > to handle this sort of logging, and if so, who is going to do that > > work? > > > > I this it's going to be a bit intrusive at this point to change > xenconsoled to do that. However it should be too hard to test. > We also need people to test and review it. All in all it seems time is > very tight. > I just read the code of virtlogd and xenconsoled. I think xenconsoled is missing at least things. From a higher level: 1. Abstraction of rotating file. 2. Abstraction of client. 3. IPC interface to libxl -- presumably we need to create a socket. Then we need to write code in libxl to use it. That then involves inventing a protocol to pass the file name to xenconsoled (assuming we still want one file per qemu). Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |