[libvirt] [PATCH v2 0/5] Extend apparmor rules for libvirt 4.6
Hi, this is a summary of things I had to touch recently for libvirt 4.6. The first two patches are re-submissions and modifications of last year which were never totally challenged, but also not pushed. The first was lost in a discussion about virt-aa-helper, whicih eventually turned out to be clear that it could not help in that case. - https://www.redhat.com/archives/libvir-list/2017-February/msg01598.html - https://www.redhat.com/archives/libvir-list/2017-March/msg00052.html The second even got a few Acks, but neither made it into upstream yet. Parts of it where introduced already, in 7edcbd02 apparmor: allow libvirt to send term signal to unconfined b482925c apparmor: support ptrace checks But there are still signals blocked with those rules, so I resubmit the remaining bit. Also I added the Acks to the resubmission. The third&fourth change came in recently via various bug reports which I finally wanted to adress - e.g. for ceph lib or smb. If we later on spot more cases that have predictable safe paths under /tmp we can add those. Finally the fifth change was triggered by me testing libvirt 4.6 in various conditions. Some of them were in containers, and the new libvirt behavior to carry more mount points into the qemu namespace triggers the need to rewrite the existing mount-moving rules that we added last year. *Updates in V2* - added Acks to path #1 - split former patch #3 into #3/#4 to discuss /tmp access and qemu-smd individually - rewrote reasoning and concerns as well as TODOs to improve later in regard to the /tmp related commits #3/#4 - Updated the rule since the trailing {,/} is not needed after ** Christian Ehrhardt (5): apparmor: allow openGraphicsFD for virt manager >1.4 apparmor: add mediation rules for unconfined guests apparmor: allow expected /tmp access patterns apparmor: allow qemu-smb access in /tmp apparmor: allow to preserve /dev mountpoints into qemu namespaces examples/apparmor/libvirt-qemu | 20 ++++++++++++++++++++ examples/apparmor/usr.sbin.libvirtd | 24 +++++++++++++----------- 2 files changed, 33 insertions(+), 11 deletions(-) -- 2.17.1
virt-manager's UI connection will need socket access for openGraphicsFD to work - otherwise users will face a failed connection error when opening the UI view. Depending on the exact versions of libvirt and qemu involved this needs either a rule from qemu to libvirt or vice versa. Acked-by: Jamie Strandboge <jamie@canonical.com> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 3 +++ examples/apparmor/usr.sbin.libvirtd | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index df5f512487..5caf14e418 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -188,6 +188,9 @@ @{PROC}/device-tree/** r, /sys/firmware/devicetree/** r, + # allow connect with openGraphicsFD to work + unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd), + # for gathering information about available host resources /sys/devices/system/cpu/ r, /sys/devices/system/node/ r, diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 3102cab382..dd37866c2a 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -69,6 +69,11 @@ unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd//qemu_bridge_helper), signal (send) set=("term") peer=/usr/sbin/libvirtd//qemu_bridge_helper, + # allow connect with openGraphicsFD, direction reversed in newer versions + unix (send, receive) type=stream addr=none peer=(label=libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*), + # unconfined also required if guests run without security module + unix (send, receive) type=stream addr=none peer=(label=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.17.1
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@canonical.com> Acked-by: Jamie Strandboge <jamie@canonical.com> Acked-by: intrigeri <intrigeri+libvirt@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, + # Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. / r, -- 2.17.1
Several cases were found needing /tmp, for example ceph will try to list /tmp This is a compromise of security and usability: - we only allow generally enumerating the base dir - enumerating anything deeper in the dir is at least guarded by the "owner" restriction, but while that protects files of other services it won't protect qemu instances against each other as they usually run with the same user. - even with the owner restriction we only allow read for the wildcard path Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 5caf14e418..6971d3db03 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -180,6 +180,18 @@ # for rbd /etc/ceph/ceph.conf r, + # Various functions will need to enumerate /tmp (e.g. ceph), allow the base + # dir and a few known functions like samba support. + # We want to avoid to give blanket rw permission to everything under /tmp, + # users are expected to add site specific addons for more uncommon cases. + # Qemu processes usually all run as the same users, so the "owner" restriction + # prevents access to other services files, but not across different instances. + # This is a tradeoff between usability and security - if paths would be more + # predictable that would be preferred - at least for write rules we would + # want more unique paths per rule. + /{,var/}tmp/ r, + owner /{,var/}tmp/**/ r, + # for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r, -- 2.17.1
On Tue, 2018-08-14 at 08:18 +0200, Christian Ehrhardt wrote:
Several cases were found needing /tmp, for example ceph will try to list /tmp This is a compromise of security and usability: - we only allow generally enumerating the base dir - enumerating anything deeper in the dir is at least guarded by the "owner" restriction, but while that protects files of other services it won't protect qemu instances against each other as they usually run with the same user. - even with the owner restriction we only allow read for the wildcard path
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 5caf14e418..6971d3db03 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -180,6 +180,18 @@ # for rbd /etc/ceph/ceph.conf r,
+ # Various functions will need to enumerate /tmp (e.g. ceph), allow the base + # dir and a few known functions like samba support. + # We want to avoid to give blanket rw permission to everything under /tmp, + # users are expected to add site specific addons for more uncommon cases. + # Qemu processes usually all run as the same users, so the "owner" restriction + # prevents access to other services files, but not across different instances. + # This is a tradeoff between usability and security - if paths would be more + # predictable that would be preferred - at least for write rules we would + # want more unique paths per rule. + /{,var/}tmp/ r, + owner /{,var/}tmp/**/ r, + # for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r,
Thanks for the changes! The comments seem longer than 80 characters, but +1 to commit as is. -- Jamie Strandboge | http://www.canonical.com
The samba feature of qemu will place the samba config file in /tmp/qemu-smb.<PID>. But at least it has a predictable path identifying qemu-smb feature itself by an infix in the path. This is a compromise of security and usability as the "owner" restriction will not protect guests among each other. Therefore the rule added makes the feature usable, but does not allow cross guest protection. Core issue is, that it is currently impossible to predict the PID which would follow "qemu-smb-", but long term, once the samba feature would be exposed in guest XML we'd prefer a virt-aa-helper based solution that can render the samba rule on demand and with a custom PID into the per guest profile. But the same is true for manual user overrides for this feature as well, they can neither predict the PID, nor have a local include per-guest. Thereby punting this to the user to add the rule later will not make it safer, but only less usable. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 6971d3db03..350b13b824 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -191,6 +191,11 @@ # want more unique paths per rule. /{,var/}tmp/ r, owner /{,var/}tmp/**/ r, + # allow qemu smb feature specific path with write access + # TODO: This is a compromise between security and usability - once e.g. samba + # would be expressed in libvirt XML it should be added on demand via + # virt-aa-helper instead. + owner /tmp/qemu-smb.*/{,**} rw, # for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r, -- 2.17.1
On Tue, 2018-08-14 at 08:18 +0200, Christian Ehrhardt wrote:
The samba feature of qemu will place the samba config file in /tmp/qemu-smb.<PID>.
But at least it has a predictable path identifying qemu-smb feature itself by an infix in the path.
This is a compromise of security and usability as the "owner" restriction will not protect guests among each other. Therefore the rule added makes the feature usable, but does not allow cross guest protection.
Core issue is, that it is currently impossible to predict the PID which would follow "qemu-smb-", but long term, once the samba feature would be exposed in guest XML we'd prefer a virt-aa-helper based solution that can render the samba rule on demand and with a custom PID into the per guest profile.
But the same is true for manual user overrides for this feature as well, they can neither predict the PID, nor have a local include per-guest. Thereby punting this to the user to add the rule later will not make it safer, but only less usable.
While the facts are true, there is something omitted and I come to a different conclusion. It is true that the pid is unpredictable, but with the 'owner /{,var/}tmp/**/ r,' rule, it is easy for a confined process to find the directories. Also, the rule 'owner /tmp/qemu- smb.*/{,**} rw,' (below) allows writing /tmp/qemu-smb.*/ so symlink attacks are possible by a rogue VM against other VMs. Rogue VMs could also use the directory in coordinated file sharing (but I mention this only for completeness, not as an objection, since there are other rules in the policy that 'overlap' and allow this sort of thing). It is definitely a usability improvement to include the rule, but I disagree that it isn't safer without it-- your addition applies to all libvirt/apparmor users, many of whom will not use the smb feature that isn't supported by the domain xml. Now, you could argue that users that never use the smb feature aren't affected by the proposed global rule (which is true), but omitting this patch, users can add the glob rule to the per-VM site policy in /etc/apparmor.d/libvirt/libvirt-<uuid> for only the VMs they need it. This might be useful if they, for example, have one trusted VM that uses the smb feature and other untrusted VMs that do not. With the global rule, the untrusted VMs have access by default. These concerns are somewhat contrived and I'm ambivalent about the addition, but it bothers me that we are adding a rule for a use case that isn't directly supported by libvirt. +0 as is. If you can demonstrate that qemu guards against symlink attacks on the dir and is otherwise safe from attack (eg, open(..., O_CREAT|O_EXCL) followed by unlink(...)), etc, etc then I could be persuaded to give a +1.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 6971d3db03..350b13b824 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -191,6 +191,11 @@ # want more unique paths per rule. /{,var/}tmp/ r, owner /{,var/}tmp/**/ r, + # allow qemu smb feature specific path with write access + # TODO: This is a compromise between security and usability - once e.g. samba + # would be expressed in libvirt XML it should be added on demand via + # virt-aa-helper instead. + owner /tmp/qemu-smb.*/{,**} rw,
# for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r, -- Jamie Strandboge | http://www.canonical.com
On Wed, Aug 15, 2018 at 7:35 PM Jamie Strandboge <jamie@canonical.com> wrote:
On Tue, 2018-08-14 at 08:18 +0200, Christian Ehrhardt wrote:
The samba feature of qemu will place the samba config file in /tmp/qemu-smb.<PID>.
But at least it has a predictable path identifying qemu-smb feature itself by an infix in the path.
This is a compromise of security and usability as the "owner" restriction will not protect guests among each other. Therefore the rule added makes the feature usable, but does not allow cross guest protection.
Core issue is, that it is currently impossible to predict the PID which would follow "qemu-smb-", but long term, once the samba feature would be exposed in guest XML we'd prefer a virt-aa-helper based solution that can render the samba rule on demand and with a custom PID into the per guest profile.
But the same is true for manual user overrides for this feature as well, they can neither predict the PID, nor have a local include per-guest. Thereby punting this to the user to add the rule later will not make it safer, but only less usable.
While the facts are true, there is something omitted and I come to a different conclusion. It is true that the pid is unpredictable, but with the 'owner /{,var/}tmp/**/ r,' rule, it is easy for a confined process to find the directories. Also, the rule 'owner /tmp/qemu- smb.*/{,**} rw,' (below) allows writing /tmp/qemu-smb.*/ so symlink attacks are possible by a rogue VM against other VMs. Rogue VMs could also use the directory in coordinated file sharing (but I mention this only for completeness, not as an objection, since there are other rules in the policy that 'overlap' and allow this sort of thing).
It is definitely a usability improvement to include the rule, but I disagree that it isn't safer without it-- your addition applies to all libvirt/apparmor users, many of whom will not use the smb feature that isn't supported by the domain xml. Now, you could argue that users that never use the smb feature aren't affected by the proposed global rule (which is true), but omitting this patch, users can add the glob rule to the per-VM site policy in /etc/apparmor.d/libvirt/libvirt-<uuid> for only the VMs they need it. This might be useful if they, for example, have one trusted VM that uses the smb feature and other untrusted VMs that do not. With the global rule, the untrusted VMs have access by default.
These concerns are somewhat contrived and I'm ambivalent about the addition, but it bothers me that we are adding a rule for a use case that isn't directly supported by libvirt. +0 as is.
Thanks for laying out the security concerns on this in detail. I agree, this might be too much for a general rule and has to stay out of the abstraction. We'd have to wait for the feature to be supported by libvirt to fully support it. Even then we might not have the pid at the time the rule is created since qemu was not yet spawned at that point.
If you can demonstrate that qemu guards against symlink attacks on the dir and is otherwise safe from attack (eg, open(..., O_CREAT|O_EXCL) followed by unlink(...)), etc, etc then I could be persuaded to give a +1.
I can't, therefore I'll abandon this change for now.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/libvirt-qemu | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 6971d3db03..350b13b824 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -191,6 +191,11 @@ # want more unique paths per rule. /{,var/}tmp/ r, owner /{,var/}tmp/**/ r, + # allow qemu smb feature specific path with write access + # TODO: This is a compromise between security and usability - once e.g. samba + # would be expressed in libvirt XML it should be added on demand via + # virt-aa-helper instead. + owner /tmp/qemu-smb.*/{,**} rw,
# for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r, -- Jamie Strandboge | http://www.canonical.com
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Libvirt now tries to preserve all mounts under /dev in qemu namespaces. The old rules only listed a set of known paths but those are no more enough. I found some due to containers like /dev/.lxc/* and such but also /dev/console and /dev/net/tun. Libvirt is correct to do so, but we can no more predict the names properly, so we modify the rule to allow a wildcard based pattern matching what libvirt does. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/usr.sbin.libvirtd | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 3ff43c32a2..8625862ced 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -33,17 +33,11 @@ mount options=(rw,rslave) -> /, mount options=(rw, nosuid) -> /{var/,}run/libvirt/qemu/*.dev/, - mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, - mount options=(rw, move) /dev/hugepages/ -> /{var/,}run/libvirt/qemu/*.hugepages/, - mount options=(rw, move) /dev/mqueue/ -> /{var/,}run/libvirt/qemu/*.mqueue/, - mount options=(rw, move) /dev/pts/ -> /{var/,}run/libvirt/qemu/*.pts/, - mount options=(rw, move) /dev/shm/ -> /{var/,}run/libvirt/qemu/*.shm/, - - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.hugepages/ -> /dev/hugepages/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.mqueue/ -> /dev/mqueue/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.pts/ -> /dev/pts/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.shm/ -> /dev/shm/, + # libvirt provides any mounts under /dev to qemu namespaces + mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, + mount options=(rw, move) /dev/** -> /{var/,}run/libvirt/qemu/*{/,}, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*{/,} -> /dev/**, network inet stream, network inet dgram, -- 2.17.1
On Tue, 2018-08-14 at 08:18 +0200, Christian Ehrhardt wrote:
Libvirt now tries to preserve all mounts under /dev in qemu namespaces. The old rules only listed a set of known paths but those are no more enough.
I found some due to containers like /dev/.lxc/* and such but also /dev/console and /dev/net/tun.
Libvirt is correct to do so, but we can no more predict the names properly, so we modify the rule to allow a wildcard based pattern matching what libvirt does.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> --- examples/apparmor/usr.sbin.libvirtd | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 3ff43c32a2..8625862ced 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -33,17 +33,11 @@ mount options=(rw,rslave) -> /, mount options=(rw, nosuid) -> /{var/,}run/libvirt/qemu/*.dev/,
- mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, - mount options=(rw, move) /dev/hugepages/ -> /{var/,}run/libvirt/qemu/*.hugepages/, - mount options=(rw, move) /dev/mqueue/ -> /{var/,}run/libvirt/qemu/*.mqueue/, - mount options=(rw, move) /dev/pts/ -> /{var/,}run/libvirt/qemu/*.pts/, - mount options=(rw, move) /dev/shm/ -> /{var/,}run/libvirt/qemu/*.shm/, - - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.hugepages/ -> /dev/hugepages/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.mqueue/ -> /dev/mqueue/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.pts/ -> /dev/pts/, - mount options=(rw, move) /{var/,}run/libvirt/qemu/*.shm/ -> /dev/shm/, + # libvirt provides any mounts under /dev to qemu namespaces + mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, + mount options=(rw, move) /dev/** -> /{var/,}run/libvirt/qemu/*{/,}, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*{/,} -> /dev/**,
+1 for the rules. Please change '{var/,}' to '{,var/}' and '{/,}' to '{,/}' since, while equivalent, the latter is a more widely use rule style (I recognize that the previous rules used '{var/,}'). -- Jamie Strandboge | http://www.canonical.com
[...]
+ mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, + mount options=(rw, move) /dev/** -> /{var/,}run/libvirt/qemu/*{/,}, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, + mount options=(rw, move) /{var/,}run/libvirt/qemu/*{/,} -> /dev/**,
+1 for the rules. Please change '{var/,}' to '{,var/}' and '{/,}' to '{,/}' since, while equivalent, the latter is a more widely use rule style (I recognize that the previous rules used '{var/,}').
Ok, the change will be done before pushing and adding your ack then. Anyone else with a +1/-1 on this?
Ok, with acks of last year and new ones in and no other feedback nor any Freeze atm I'm pushing these changes any minute. The qemu-smb related one will be dropped, the others pushed with the latest cleanups as discussed in the per-patch threads. Thanks everybody for your participation! On Tue, Aug 14, 2018 at 8:18 AM Christian Ehrhardt < christian.ehrhardt@canonical.com> wrote:
Hi, this is a summary of things I had to touch recently for libvirt 4.6. The first two patches are re-submissions and modifications of last year which were never totally challenged, but also not pushed.
The first was lost in a discussion about virt-aa-helper, whicih eventually turned out to be clear that it could not help in that case. - https://www.redhat.com/archives/libvir-list/2017-February/msg01598.html - https://www.redhat.com/archives/libvir-list/2017-March/msg00052.html
The second even got a few Acks, but neither made it into upstream yet. Parts of it where introduced already, in 7edcbd02 apparmor: allow libvirt to send term signal to unconfined b482925c apparmor: support ptrace checks But there are still signals blocked with those rules, so I resubmit the remaining bit. Also I added the Acks to the resubmission.
The third&fourth change came in recently via various bug reports which I finally wanted to adress - e.g. for ceph lib or smb. If we later on spot more cases that have predictable safe paths under /tmp we can add those.
Finally the fifth change was triggered by me testing libvirt 4.6 in various conditions. Some of them were in containers, and the new libvirt behavior to carry more mount points into the qemu namespace triggers the need to rewrite the existing mount-moving rules that we added last year.
*Updates in V2* - added Acks to path #1 - split former patch #3 into #3/#4 to discuss /tmp access and qemu-smd individually - rewrote reasoning and concerns as well as TODOs to improve later in regard to the /tmp related commits #3/#4 - Updated the rule since the trailing {,/} is not needed after **
Christian Ehrhardt (5): apparmor: allow openGraphicsFD for virt manager >1.4 apparmor: add mediation rules for unconfined guests apparmor: allow expected /tmp access patterns apparmor: allow qemu-smb access in /tmp apparmor: allow to preserve /dev mountpoints into qemu namespaces
examples/apparmor/libvirt-qemu | 20 ++++++++++++++++++++ examples/apparmor/usr.sbin.libvirtd | 24 +++++++++++++----------- 2 files changed, 33 insertions(+), 11 deletions(-)
-- 2.17.1
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
participants (2)
-
Christian Ehrhardt -
Jamie Strandboge