<div dir="ltr">Thanks john, that will be of great help.<div> </div><div>I am trying to capture apparmor profile for hardening container, and i was not able to get the complete profile.</div><div> </div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 20, 2020 at 5:38 PM John Johansen <<a href="mailto:john.johansen@canonical.com">john.johansen@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="mailto:john.johansen@canonical.com" target="_blank">john.johansen@canonical.com</a> <mailto:<a href="mailto:john.johansen@canonical.com" target="_blank">john.johansen@canonical.com</a>>> 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 > <a href="mailto:AppArmor@lists.ubuntu.com" target="_blank">AppArmor@lists.ubuntu.com</a> <mailto:<a href="mailto:AppArmor@lists.ubuntu.com" target="_blank">AppArmor@lists.ubuntu.com</a>> > Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/apparmor" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/apparmor</a> > </blockquote></div>