[lxc-users] apparmor kernel log entries

[Serge Hallyn]

Quoting Mark Chaney (mail at lists.macscr.com):
> any suggestions for resolving this warning/error i keep getting on
> my lxc host (ubuntu 14.04 lts). All my guests are privileged. I have
> no idea what container is even sparking the log entry.
> 
> Dec 22 11:39:04 backup kernel: [498830.030751] type=1400
> audit(1450805944.611:17688): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=7448 comm="lsof"
> requested_mask="read" denied_mask="read" peer="unconfined"
> Dec 22 11:41:22 backup kernel: [498967.665959] type=1400
> audit(1450806082.172:17737): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=13992 comm="ps"
> requested_mask="trace" denied_mask="trace" peer="unconfined"
> Dec 22 11:43:29 backup kernel: [499094.819757] type=1400
> audit(1450806209.256:17753): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=18458 comm="ps"
> requested_mask="trace" denied_mask="trace" peer="unconfined"
> Dec 22 11:45:22 backup kernel: [499207.838369] type=1400
> audit(1450806322.216:17754): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=20840 comm="ps"
> requested_mask="trace" denied_mask="trace" peer="unconfined"
> Dec 22 11:45:22 backup kernel: [499207.839167] type=1400
> audit(1450806322.216:17757): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=20840 comm="ps"
> requested_mask="trace" denied_mask="trace" peer="unconfined"
> Dec 22 11:51:22 backup kernel: [499568.111011] type=1400
> audit(1450806682.289:17789): apparmor="DENIED" operation="ptrace"
> profile="lxc-container-default" pid=2115 comm="ps"
> requested_mask="trace" denied_mask="trace" peer="unconfined"

It looks to me like you have a task in the container doing ps or lsof
while it is able to see a host task.  This can happen for instance
while a host task is in the middle of transitioning into a
container (i.e. lxc-attach).  The 'ptrace' check is used for several
types of checks (not just the ptrace syscall).  I'm not sure why you
have so many of these, but it is correct for the container task to
not be allowed ptrace access to something unconfined.