[apparmor] Regarding apparmor in container

[swarna latha]

Thanks john, that will be of great help.

I am trying to capture apparmor profile for hardening container, and i was
not able to get the complete profile.



On Tue, Oct 20, 2020 at 5:38 PM John Johansen <john.johansen at canonical.com>
wrote:

> On 10/20/20 2:16 PM, swarna latha wrote:
> > Hi,
> >
> > i see similar behaviour, i am not able to use mrCx, mrUx options to
> capture the apparmor logs of the process inside container.
> >
> > The process in the container is executed only if give ix. But i am not
> getting apparmor logs of this process.
> >
> that pretty much says you are hitting NO_NEW_PRIVS
>
> > is there any patch i can apply on 4.1 kernel to capture apparmor logs
> for this process.
>
> We can certainly create a patch to log something. Let me see what I can
> cherry-pick/backport to 4.1
>
> >
> > Thanks,
> > Swarna
> >
> > On Tue, Oct 20, 2020 at 4:55 PM John Johansen <
> john.johansen at canonical.com <mailto:john.johansen at canonical.com>> wrote:
> >
> >     oops forgot to check that you were in the reply, so this only went to
> >     simon and the list
> >
> >     On 10/20/20 12:55 PM, Simon Deziel wrote:
> >     > On 2020-10-20 3:46 p.m., swarna latha wrote:
> >     >> Thanks john for the quick reply..
> >     >>
> >     >> My kernel version is 4.1.51-1.19
> >     >>
> >     >> Tried below logging options, but didnt help. Not able to get
> logs, what is
> >     >> blocking apparmor to play video.
> >     >>  echo -n "noquiet" /sys/module/apparmor/parameters/audit
> >     >> echo 0> /sys/module/apparmor/parameters/debug
> >     >
> >     > So far, what I've seen with containers is that dmesg/kernel logs
> are
> >     > only visible from the host's context, not the containers
> themselves.
> >     >
> >
> >     this is usually true. In addition are you getting no apparmor logs,
> or
> >     just no apparmor log for this issue. Those are two different things
> to
> >     debug.
> >
> >     With that said I suspect the issue is NO_NEW_PRIVS, see prctl(2).
> When
> >     that is set apparmor can not transition its profile, and will fail
> execs
> >     that request a profile transition.
> >
> >     Looking at the 4.1 kernel apparmor is not auditing NO_NEW_PRIVS
> >     causing a failure in profile transitions (its an external restriction
> >     and not exactly part of apparmor). Which would also align with what
> >     you are seeing.
> >
> >     When it comes to NO_NEW_PRIVS on the 4.1 kernel you basically have
> >     three choices.
> >
> >     1. Don't transition the profile, use ix
> >
> >     2. transition the profile before the container does
> >         prctl(PR_SET_NO_NEW_PRIVS).
> >
> >     3. If a container task is unconfined it can transition into a
> >        profile even after NO_NEW_PRIVS is set but once it does that it
> >        won't be able to transition the profile again.
> >
> >     --
> >     AppArmor mailing list
> >     AppArmor at lists.ubuntu.com <mailto:AppArmor at lists.ubuntu.com>
> >     Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/apparmor
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20201021/ee55b3a2/attachment.html>