In addition to what Joshua said (which is correct and the likely cause - permissive mode automatically adds the permission to the AVC after the first denial to avoid flooding the logs with repeated identical denials), other possible issues you might encounter include: 1) The kernel ratelimits audit messages by default, which can suppress denials if too many occur in a short period of time. In our kernel trees, we have a patch to disable the rateilmiting for development to ensure we do not miss any denials during board bringup. This is not an issue once auditd is running.
2) Userspace code may take different paths based on what access is granted, and therefore you might see different denials in permissive vs enforcing. Typically this shows up when a userspace process tries to search a directory that isn't accessible in policy; if in permissive, you'll see denials for the directory and all file within it, whereas in enforcing you won't get past the initial search denial on the directory. However, for the most part, they should be identical. On Tue, Nov 19, 2013 at 4:53 AM, Jaejyn Shin <[email protected]> wrote: > Hi SEAndroid > > A denial log is printed during Enforcing-mode but it is not printed during > permissive-mode. > > To check it in detail, I inserted printk at the end of avc_audit function of > avc.c. > > 551 audited = requested & avd->auditallow; > 552 if (likely(!audited)) > 553 return 0; > 554 printk(KERN_ERR "jaejyn call slow_avc_audit\n"); //jaejyn.shin > 555 return slow_avc_audit(ssid, tsid, tclass, > 556 requested, audited, denied, > 557 a, flags); > 558 } > > The 554 line was also printed during Enforcing-mode but it is not printed > during permissive-mode. > > The policies of Enforcing and Permissive are exactly same in the same image? > Or is there any difference ? > > Thank you > Best regards -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
