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