Hi Gaurav, boot.img is a must reburn image because /sepolicy under it. If there is any relabel, such as /system/bin/xxxx, I will also reburn the system.img. So basically, I have carefully taken care of this kind issue. I think it’s still not the root cause. Now, I have two clues about this issue: (1) avc size I’m reading the code under /kernel/security/selinux/avc.c I noticed that there are some macro like #define AVC_DEF_CACHE_THRESHOLD 512 #define AVC_CACHE_SLOTS 512 Are they some kind of threshold ? If the size of avc log reported is bigger than that, new avc will be abandoned ? (2) audit subsystem may drop some record when it’s satisfied with some condition like /kernel/kernel/audit.c 115/* Records can be lost in several ways: 116 0) [suppressed in audit_alloc] 117 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118 2) out of memory in audit_log_move [alloc_skb] 119 3) suppressed due to audit_rate_limit 120 4) suppressed due to audit_backlog_limit 121*/
Any comments on these two ?
Thanks. Sincerely Alan Xin From: Gaurav Gangwar [mailto:gauravgangwaar@xxxxxxxxx] Hi Alan, Do flash all the images every-time or just the boot image. if you flash only boot-image then that could be reason. Thanks and Regards Gaurav Gangwar On 5 May 2015 at 13:02, Zhi Xin <xinzhi@xxxxxxxxxxx> wrote: Hi Ravi, Thanks for analysis. I get your point. Under enforcing, if open is blocked, we never see the ioctl operation come. I agreed with you analysis. But my issue is not like this. The issue I try to say is that even under permissive, selinux cannot give out all the avc log in one time. My previous example is probably not a good one. I’d like to give a new one. For a new phone with Android lp5.0 that enabled permissive mode of SEAndroid, it reports lots of avc deny logs in one boot. And after I fix them by adding selinux policy, reburn the boot.img and boot again. I can still get avc logs, which are different from previous. Why they cannot be printed out in one time ? Thanks. Sincerely Zhi Xin From: Ravi Kumar [mailto:nxp.ravi@xxxxxxxxx] Alan, Code written in most of the cases will be checking for success on file open or device node open . Which is basically a check on file descriptor (fd) if its null ( may be failed due to selinux policy missing) it comes out of the code and never try to do a IOCTL / or any other operation on the null fd so we will not see any additional denials until we address the open. As a generally practice what i feel recommending is set the selinux mode in permissive and capture all the denials at ONE shot . Based on the denials logs collected it will be easy for us to write / define the policy at a single shot . you can use kernel cmdline for setting it in permissive or use "setenforce " cmd from root shell . Regards, Ravi
On Tue, May 5, 2015 at 8:07 AM, William Roberts <bill.c.roberts@xxxxxxxxx> wrote: Are you running in permissive or enforcing mode? Usually if you're running in enforcing mode the daemon will not be able to perform all of its tasks that it normally would thus your missing messages On May 4, 2015 7:11 PM, "Zhi Xin" <xinzhi@xxxxxxxxxxx> wrote:
|
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.