Commit 12317957ecd6c37a2fb16275dcdeeacfe25c517 introduced an incompatible
architectural change for the AppArmor security driver. Specifically,
virSecurityManagerSetAllLabel() is now called much later in
src/qemu/qemu_process.c:qemuProcessStart(). Previously, SetAllLabel() was
called immediately after GenLabel() such that after the dynamic label (profile
name) was generated, SetAllLabel() would be called to create and load the
AppArmor profile into the kernel before qemuProcessHook() was executed. With
12317957ecd6c37a2fb16275dcdeeacfe25c517, qemuProcessHook() is now called
before SetAllLabel(), such that aa_change_profile() ends up being called
before the AppArmor profile is loaded into the kernel (via ProcessLabel() in
qemuProcessHook()).
This patch addresses the change by making GenLabel() load the AppArmor
profile into the kernel after the label (profile name) is generated.
SetAllLabel() is then adjusted to only reload_profile() and append stdin_fn to
the profile when it is specified. This also makes the AppArmor driver work
like its SELinux counterpart with regard to SetAllLabel() and stdin_fn.
Passes its part of 'check' and 'syntax-check' (though
libvirt_net_rpc_la-virnetmessage.lo failed to compile and po_check
failed the syntax check for unrelated reasons).
Prior to writing this patch, the issue was discussed on IRC with Daniel
Berrange and Eric Blake. Other discussed alternatives were to do a 2
stage qemuProcessHook(), where ProcessLabel() was only called in the
second stage after the handshake. In attempting this, it still didn't
address the fact that aa_change_profile() was being called on an
unloaded profile so it was abandoned. Another idea was to create a
second private API call that the AppArmor driver would use to load the
profile that would be a no-op for the SElinux driver. I started to go
this route, but in the end it was both unneeded and too complicated once
I realized I could simply load the profile in GenLabel() and still use
SetAllLabel() to reload the profile when stdin_path was specified. The
current fix is implemented wholly within the AppArmor driver and I think
much cleaner.
Reference:
https://launchpad.net/bugs/795800
--
Jamie Strandboge |
http://www.canonical.com