If a guest runs unconfined <seclabel type='none'>, but libvirtd is
confined then the peer for signal/ptrace can only be detected as
'unconfined'. That triggers issues like:
   apparmor="DENIED" operation="signal"
   profile="/usr/sbin/libvirtd" pid=22395 comm="libvirtd"
   requested_mask="send" denied_mask="send" signal=term peer="unconfined"

To fix this add unconfined as an allowed peer for those operations.

I discussed with the apparmor folks, right now there is no better
separation to be made in this case. But there might be further down the
road with "policy namespaces with scope and view control + stacking"

This is more a use-case addition than a fix to the following two changes:
 - 3b1d19e6 AppArmor: add rules needed with additional mediation features
 - b482925c apparmor: support ptrace checks

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
 examples/apparmor/usr.sbin.libvirtd | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index 8d61d15..23e8aa3 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -61,6 +61,10 @@
   signal (send) peer=/usr/sbin/dnsmasq,
   signal (read, send) peer=libvirt-*,
 
+  # required if guests run unconfined seclabel type='none' but libvirtd is confined
+  signal (read, send) peer=unconfined,
+  ptrace (trace) peer=unconfined,
+
   # Very lenient profile for libvirtd since we want to first focus on confining
   # the guests. Guests will have a very restricted profile.
   / r,
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, 2017-12-15 at 08:52 +0100, Christian Ehrhardt wrote:
> If a guest runs unconfined <seclabel type='none'>, but libvirtd is
> confined then the peer for signal/ptrace can only be detected as
> 'unconfined'. That triggers issues like:
>    apparmor="DENIED" operation="signal"
>    profile="/usr/sbin/libvirtd" pid=22395 comm="libvirtd"
>    requested_mask="send" denied_mask="send" signal=term
> peer="unconfined"
> 
> To fix this add unconfined as an allowed peer for those operations.
> 
> I discussed with the apparmor folks, right now there is no better
> separation to be made in this case. But there might be further down
> the
> road with "policy namespaces with scope and view control + stacking"
> 
> This is more a use-case addition than a fix to the following two
> changes:
>  - 3b1d19e6 AppArmor: add rules needed with additional mediation
> features
>  - b482925c apparmor: support ptrace checks
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  examples/apparmor/usr.sbin.libvirtd | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/examples/apparmor/usr.sbin.libvirtd
> b/examples/apparmor/usr.sbin.libvirtd
> index 8d61d15..23e8aa3 100644
> --- a/examples/apparmor/usr.sbin.libvirtd
> +++ b/examples/apparmor/usr.sbin.libvirtd
> @@ -61,6 +61,10 @@
>    signal (send) peer=/usr/sbin/dnsmasq,
>    signal (read, send) peer=libvirt-*,
>  
> +  # required if guests run unconfined seclabel type='none' but
> libvirtd is confined
> +  signal (read, send) peer=unconfined,
> +  ptrace (trace) peer=unconfined,
> +
>    # Very lenient profile for libvirtd since we want to first focus
> on confining
>    # the guests. Guests will have a very restricted profile.
>    / r,

These rules are unfortunate, but it is important to note that this is
in the libvirtd profile, not the guest profiles. As mentioned in the
contextual diff, the profile is intentionally very lenient since
libvirtd is necessarily highly trusted. As Christian mentioned, we
discussed that this is the best option for the moment. +1 to apply.
Thanks for the patch!

-- 
Jamie Strandboge             | http://www.canonical.com--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Hi,

Jamie Strandboge:
> These rules are unfortunate, but it is important to note that this is
> in the libvirtd profile, not the guest profiles. As mentioned in the
> contextual diff, the profile is intentionally very lenient since
> libvirtd is necessarily highly trusted. As Christian mentioned, we
> discussed that this is the best option for the moment. +1 to apply.
> Thanks for the patch!

Same here, these rules are much less problematic than they look like
at first glance ⇒ +1

Cheers,
-- 
intrigeri

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list