On 12/19/2016 03:17 AM, intrigeri wrote: > Guido Günther: >>> Well, info="Failed name lookup - disconnected path" does ring a bell. >>> It might be that the libvirtd profile needs the attach_disconnected >>> flag (there are plenty of examples that do in my /etc/apparmor.d). >>> Can you please try and report back? > >> That worked, reassigning to libvirt. Thanks a lot! > > :) > >> That said this is a behaviour change in apparmor / kernel that breaks >> existing profiles. Do we have any means to deal with such things? >
There haven't been any upstream changes to the apparmor kernel module besides bug fixes. So unless you are running a kernel based off of the dev patches, like the ubuntu kernel does, then not likely. With that said there have been several kernel changes that could cause this or even libvirt changes that could require new apparmor policy. eg. the 4.8 kernel picked up patch 9f834ec18defc369d73ccf9e87a2790bfa05bf46 binfmt_elf: switch to new creds when switching to new mm which changes the order of certain checks, and requires changes to policy in some cases. However looking at the bug report, that commit does not appear to be responsible. From the log messages [ 53.910082] audit: type=1400 audit(1481125685.045:103): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1353 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933255] audit: type=1400 audit(1481125685.069:104): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933267] audit: type=1400 audit(1481125685.069:105): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933274] audit: type=1400 audit(1481125685.069:106): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933282] audit: type=1400 audit(1481125685.069:107): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933290] audit: type=1400 audit(1481125685.069:108): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 53.933297] audit: type=1400 audit(1481125685.069:109): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 it looks like use of namespacing, where a file descriptor is being passed into a namespace where it is not connected. Resulting in apparmor denying its access. Unfortunately apparmor's support for this is very hackish atm (proper support is a wip). The only thing you can do is add the flag attach_disconnected to the profile. This will force apparmor to attach the the file to the tasks namespace, providing a point to mediate it. eg of adding the flag /bin/foo flags=(attach_disconnected) { ... } /binfoo flags=(complain, attach_disconnected) { ... } /bin/foo (attach_disconnected) { ... } /bin/foo (complain, attach_disconnected) { ... } the flags= form is generally preferred but either will work. Also note that the profile will need new rules added to allow access to the file, as attach_disconnected will only "attach" the file to the namespace, resulting in a name that can be mediated off of. > Not sure what we can do about it. I'm personally not closely tracking > the kernel side of things. Ideally the upstream AppArmor mailing list > would be notified when such changes are merged in Linux mainline. > Cc'ing the upstream mailing list: what do you think? > Haha, I wish. Its general courtesy to CC the maintainer of a subsystem before a commit is made but it doesn't always happen. And because the LSM has hooks into all parts of the kernel changes can occur that affect an LSM without touching the LSM. eg. commit 9f834ec18 that was mentioned above. We do monitor for changes but without complete test coverage for every possible change, it is impossible to guarantee that we will catch all changes that can affect apparmor enforcement. However the bigger problem by far is applications changing their own code, either to rework how something is done or make use of new features (namespaces, seccomp) without the code ever being tested under a given LSM (apparmor in this case). I can't blame them for this as often the LSMs policy restrictions are maintained outside of the project, and the application devs don't have the expertise to test or update the policy themselves. Worse most LSM policy is, by design, made to be modifiable by an admin, to meet a sites security policy needs, not what an application thinks it wants so at best an project can provide a reference policy for their application, that may not get updated or used at any given site. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor