[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.