On Tue, 2018-03-20 at 13:08 +0100, Christian Ehrhardt wrote:
> Recent changes have made implementing this mandatory to hot add any
> memory.
> Implementing this in apparmor fixes this as well as allows hot-add of
> nvdimm
> tpye memory with an nvdimmPath set generating a AppArmor rule for
> that
> path.
>
> Example hot adding:
> <memory model='nvdimm'>
> <source>
> <path>/tmp/nvdimm-test</path>
> </source>
> <target>
> <size unit='KiB'>524288</size>
> <node>0</node>
> </target>
> </memory>
> Creates now:
> "/tmp/nvdimm-test" rwk,
>
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx>
> ---
> src/security/security_apparmor.c | 50
> ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/src/security/security_apparmor.c
> b/src/security/security_apparmor.c
> index a989992..4ae1e3d 100644
> --- a/src/security/security_apparmor.c
> +++ b/src/security/security_apparmor.c
> @@ -718,6 +718,53 @@
> AppArmorRestoreSecurityDiskLabel(virSecurityManagerPtr mgr,
>
> /* Called when hotplugging */
> static int
> +AppArmorSetMemoryLabel(virSecurityManagerPtr mgr,
> + virDomainDefPtr def,
> + virDomainMemoryDefPtr mem)
> +{
> + virSecurityLabelDefPtr secdef;
> +
> + switch ((virDomainMemoryModel) mem->model) {
> + case VIR_DOMAIN_MEMORY_MODEL_NVDIMM:
> + secdef = virDomainDefGetSecurityLabelDef(def,
> SECURITY_APPARMOR_NAME);
> + if (!secdef || !secdef->relabel)
> + return 0;
> +
> + if (!virFileExists(mem->nvdimmPath)) {
> + virReportError(VIR_ERR_INTERNAL_ERROR,
> + _("%s: \'%s\' does not exist"),
> + __func__, mem->nvdimmPath);
> + return -1;
> + }
> +
> + return reload_profile(mgr, def, mem->nvdimmPath, true);
> + break;
> + case VIR_DOMAIN_MEMORY_MODEL_NONE:
> + case VIR_DOMAIN_MEMORY_MODEL_DIMM:
> + case VIR_DOMAIN_MEMORY_MODEL_LAST:
> + break;
> + }
> +
> + return 0;
> +}
> +
> +
> +static int
> +AppArmorRestoreMemoryLabel(virSecurityManagerPtr mgr,
> + virDomainDefPtr def,
> + virDomainMemoryDefPtr mem
> ATTRIBUTE_UNUSED)
> +{
> + virSecurityLabelDefPtr secdef =
> + virDomainDefGetSecurityLabelDef(def,
> SECURITY_APPARMOR_NAME);
> +
> + if (!secdef || !secdef->relabel)
> + return 0;
> +
This secdef check is done already in reload_profile.
> + return reload_profile(mgr, def, NULL, false);
Calling this with NULL means that virt-aa-helper will be called and
remove the mem file, but will it also remove anything else that was
hotplugged and not present in 'xml = virDomainDefFormat(def, ...)'?
I've not looked at this in a while, so maybe it's ok (it seems like
this is what the various other AppArmorRestore* functions do after
all). A test case for hotplugging all these different devices and
hotunplugging each would be good to show if hotunplugging one
inadvertently removes rules for other devices that are still
hotplugged.
> +}
> +
> +/* Called when hotplugging */
> +static int
> AppArmorSetSecurityImageLabel(virSecurityManagerPtr mgr,
> virDomainDefPtr def,
> virStorageSourcePtr src)
> @@ -1115,6 +1162,9 @@ virSecurityDriver virAppArmorSecurityDriver = {
> .domainSetSecurityImageLabel =
> AppArmorSetSecurityImageLabel,
> .domainRestoreSecurityImageLabel =
> AppArmorRestoreSecurityImageLabel,
>
> + .domainSetSecurityMemoryLabel = AppArmorSetMemoryLabel,
> + .domainRestoreSecurityMemoryLabel =
> AppArmorRestoreMemoryLabel,
> +
> .domainSetSecurityDaemonSocketLabel =
> AppArmorSetSecurityDaemonSocketLabel,
> .domainSetSecuritySocketLabel =
> AppArmorSetSecuritySocketLabel,
> .domainClearSecuritySocketLabel =
> AppArmorClearSecuritySocketLabel,
--
Jamie Strandboge | http://www.canonical.comAttachment:
signature.asc
Description: This is a digitally signed message part
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
