[PATCH 3/8] apparmor: allow virt-aa-helper nameservices

[Christian Ehrhardt]

On Mon, Aug 3, 2020 at 5:05 PM Jamie Strandboge <jamie at canonical.com> wrote:

> 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.
And in the Debian counterpart of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882979 they headed to
"nss should be save" right away.

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 at 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
>


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200804/09317a93/attachment-0001.htm>