[apparmor] Bug#847370: Recent apparmor broke "virsh lxc-enter"

[John Johansen]

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.