On 12/07/2011 06:12 AM, Dor Laor wrote:
On 12/07/2011 12:52 PM, Daniel P. Berrange wrote:
On Wed, Dec 07, 2011 at 12:34:01PM +0200, Dor Laor wrote:
On 12/07/2011 06:03 AM, Michael Roth wrote:
This adds a command-line option, -b/--blacklist, that accepts a
comma-seperated list of RPCs to disable, or prints a list of
available RPCs if passed "?".
In consequence this also adds general blacklisting and RPC listing
facilities to the new QMP dispatch/registry facilities, should the
QMP monitor ever have a need for such a thing.
Beyond run time disablement, how easy it is to compile out some of
the general commands such as exec/file-handling?
Security certifications like common criteria usually ask to compile
out anything that might tamper security.
I don't think that's really relevant/needed. As discussed on the
call yesterday, this is security theatre, because nothing can prevent
the host admin from accessing guest RAM or disk data. AFAIK the
virtualization related security certifications acknowledge this
already& don't make any claims about security of guests against
a malicious host admin. In any case, a suitable SELinux policy for
the guest agent could prevent arbitrary file/binary access via
generic 'exec' / 'file-read' commands, in a manner that is sufficient
to satisfy security certications.
I absolutely agree that the hypervisor can tweak the guest in multiple
ways. Nevertheless there are two reasons I asked it:
1. Reduce code and noise from security reviewers eyes.
We were asked to do exactly that for other qemu functionality that
is included but does not run at all. It's just makes the review
faster.
Actually removing the code, or compiling it out?
If it's a matter of compiling it out, the best solution I can think of
is having the QAPI code generators create a #define <rpc> for each RPC,
then wrapping the implementations inside an #ifdef <rpc>. That way you
could compile out the code by simply modifying the schema.
That said, I'd really like to avoid having distros get into the habit of
extensively modifying their guest agent source outside of bug fixes and
whatnot, I think it'll cause too many problems down the road. From a
management perspective, if you're running a cloud with multiple distros,
it'll be really difficult to account for agents that have been modified
or crippled in various ways.
Perhaps we only need, say, shutdown, for ovirt, and compile out the
rest, but maybe a customer wants to run their RHEL guest in home-brewed
environment where they use qemu-ga file read/write to handle a specific
set of guest activation procedures. Now they need a new agent package.
It's a whole lot of hassle for host/guest admins for the sake of saving
a security reviewer a bit of investigating that'll lead right back to
the general operating premise that you have to trust your host
administrators before any chain of trust can be established.
At least with this interface we can provide some semblance of relief to
users with specific security concerns, but don't have to work with
distros to re-package agents when those concerns collide with
requirements on the host side. We can just check to see if they disabled
the functionality and request they re-enable due to <reason> by updating
their configs.
2. Every piece of code is a risk for exploit
Imagine that a bug/leak/use-after-free in the blacklist command or
the exec command on qemu exists and allows attacked to gain control
of qemu.
A host can never assume that a guest [agent] can be trusted. qemu-ga
might've been replaced completely by a malicious guest admin, thus
circumventing any steps a distro has taken to harden it. Fortunately a
guest can only affect memory outside it's address space by going through
the virtio-serial/QMP layer. So we can focus our efforts on hardening
the transport and json parser layers, and a lot of work has gone into
that already (placing limits on token size, recursion depth, etc). So
that's more an issue that needs to be addressed on the qemu side, and is
independent of any particular RPC implementation on the guest side.