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@canonical.com>
> ---
>  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.com