On Mon, 2018-08-13 at 16:39 +0200, Christian Ehrhardt wrote:
If a guest runs unconfined <seclabel type='none'>, but
libvirtd is
confined then the peer for signal 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(a)canonical.com>
Acked-by: Jamie Strandboge <jamie(a)canonical.com>
Acked-by: intrigeri <intrigeri+libvirt(a)boum.org>
---
examples/apparmor/usr.sbin.libvirtd | 3 +++
1 file changed, 3 insertions(+)
diff --git a/examples/apparmor/usr.sbin.libvirtd
b/examples/apparmor/usr.sbin.libvirtd
index dd37866c2a..3ff43c32a2 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -74,6 +74,9 @@
# unconfined also required if guests run without security module
unix (send, receive) type=stream addr=none
peer=(label=unconfined),
+ # required if guests run unconfined seclabel type='none' but
libvirtd is confined
+ signal (read, send) peer=unconfined,
A tad unfortunate, but again, the libvirtd profile is meant to be super
strict. +1 to apply
--
Jamie Strandboge |
http://www.canonical.com