On Mon, 03 Aug 2020, Christian Ehrhardt wrote:
> Since quite a while libvirt-aa-helper triggers nss related apparmor
> denials like:
> operation="open" profile="virt-aa-helper" name="/etc/nsswitch.conf"
> operation="open" profile="virt-aa-helper" name="/etc/host.conf"
> operation="open" profile="virt-aa-helper" name="/etc/resolv.conf"
> operation="open" profile="virt-aa-helper" name="/etc/hosts"
>
> Rules to allow these are in Debian [1] / Ubuntu [2] since quite a
> while but do not seem to be specific to those distributions.
>
> There can be much more reasons than one would think to inadvertently
> use/trigger nameservices as can be seen in the comments in
> profiles/apparmor.d/abstractions/nameservice at [3].
> The nameservices abstraction provides a nice and upgrade safe
> way to cover all of them.
That is possible, initially we only had rules that looked like the head of
/etc/apparmor.d/abstractions/nameservice which is like /etc/{group,gai.conf,nssswitch.conf,hosts}
But you are right, chances are that is reads that by accident. Back then in bug
1513367 the discussion was a bit complex as it was about three different apparmor
denials at once.
All of the old reports called the denials either noise or a slowdown - so looking back there didn't seem to be a functional impact.
Which would be a +1 to your theory.
I was removing the rule, but just as when this bug came up at first it isn't triggering for various test environments and cases that I tried.
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882979
> [2]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1546674
> [3]: https://gitlab.com/apparmor/apparmor
>
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
> src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in
> index dd18c8ab89..dfc61e8de4 100644
> --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in
> +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in
> @@ -2,6 +2,7 @@
>
> profile virt-aa-helper @libexecdir@/virt-aa-helper {
> #include <abstractions/base>
> + #include <abstractions/nameservice>
nameservice brings in network rules so this is actually a lot of access.
Why is it reaching out to nss? Is it just cause some library happens to
look at /etc/nsswitch.conf and pull in other things or does it actually
need networking? I suspect the former. If my suspicion is true, perhaps
instead:
# virt-aa-helper dependent libraries read (and if successful, other
# files) but virt-aa-helper itself doesn't require the access, so
# silence the denial.
deny /etc/nsswitch.conf r,
I like your suggestion, especially as this isn't the profile for libvirtd but just virt-aa-helper.
That denial seems non critical while most likely prevents the follow up access.
I was looking for nss libs in virt-aa-helper context that "might be required" but the only path
to it seems to come up in regard to rbd support which isn't needed to render apparmor
rules in virt-aa-helper.
I'd really want to make it part of a v2 submission, but feel that it is wrong to do so without
being able to re-create it to know for sure where the access was from exactly.
I was trying back to 16.04 (being the time this was reported) with local disks (that is what
triggered it back then) or ceph (as rbd is the only path to libnss3) :-/
For now I'm just removing this commit from the list of proposed changes.
--
Jamie Strandboge | http://www.canonical.com