On Tue, Jul 17, 2012 at 05:55:19PM +0200, Dario Faggioli wrote: > On Tue, 2012-07-17 at 11:33 -0400, Konrad Rzeszutek Wilk wrote: > > > The only thing that comes to my mind is PCI passthrough, as it probably > > > could be thought at something allowing physical memory accesses... Or is > > > the control Xen/qemu provides over it sufficient? (Again, I think the > > > same could apply to KVM, right?). > > > > Right, and also kexec for example. There is code loaded from userspace > > binary into the kernel to deal with a crashed kernel. Its called > > purgatory code. > > > I see. > > > What I am not clear is how far the "chain of trust" needs to go - b/c > > this also would imply module signing - which is right now _not_ in the > > upstream kernel. > > > It sure does, and in fact, module signing figures in the (still drafted) > Fedora's plan: http://mjg59.dreamwidth.org/12368.html ("Signed modules > are obviously troubling from a user perspective. We'll be signing all > the drivers that we ship [...]"). > > The X server is also mentioned there, so I guess qemu (it open /dev/mem > as root after all, doesn't it?) could be a candidate either? :-O Right, if you follow that logic, then v86d needs to be signed. I am not sure about the Xen toolstack - it makes ioctl calls in /dev/xen/privcmd so that the kernel alters the underlaying PFNs to point to the guest memory. Should those be signed too? Not really sure what the criteria is for signing something when it comes to doing guest operations. I would think not, b/c what you are doing is an up-call. And the up-call is verified by a trusted agent (kernel). Then the kernel makes a hypercall up-call to a another truested agent (hypervisor), and then the hypervisor does it stuff. If we were divergent from this chain of operation and muddling with /dev/mem or some other non-inspected method then perhaps we should have sign the binary? Thought from an attack perspective - what if I made a little C code that did the ioctls, openned a window to a guest and injected some binary blob (virus). Obviously it needs to run as root, so if I find an exploit and run it I can do that. Hmm, so if we the ioctl (privcmd) check the signature of the program to always be on the matching signature list (so only libxenguest or xl or whatever has the ELF signature part) then we can thwart that attach vector. Then we "only" need to worry about possible exploits in 'xl'. But if this the train of thinking, then it would seem like you need to have signatures for every application that does any type of ioctls. So you would need to sign 'fdisk', 'vim', 'sysctl'.. ? And if you tried to run your own compiled 'fdisk' you wouldn't be able to, unless you get your own self-signed key in the key repo or get the $99 cert and start signging the binaries after compiling. Or perhaps I am thinking way too much? This doesn't seem any different than TPM / tboot and its chain of trust concept. Except that those stopped with the kernel and modules I believe. > > Thanks and Regards, > Dario > > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > -- xen mailing list xen@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/xen
