RE: Give out all the avc logs in ome time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
Sent: 2015
55 16:39
To: Zhi Xin
Cc: Ravi Kumar; William Roberts; selinux@xxxxxxxxxxxxx
Subject: Re: Give out all the avc logs in ome time

 

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]
Sent: 2015
55 13:56
To: William Roberts
Cc: Zhi Xin; selinux@xxxxxxxxxxxxx
Subject: Re: Give out all the avc logs in ome time

 

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:

Hi All,

 

In my daily work, I’m always solving the selinux deny as presented by avc log. But I found that, for one particular test, selinux cannot give me all the avc deny log in one time, which has slowed down a lot of my daily work.

 

For example, I trigger a process called test_daemon to access a /dev/test_device in a particular test. Totally, it should have “open, read, write, ioctl” for permissions. But for one time test, I only catch “open, read” related avc log. And only after I have merged a patch to give the “open” and “read” permission, I rerun the test. The “write ioctl” related avc  logs start to occur. So my question is how can I get “open, read, write, ioctl” avc log in one test.

 

I have done a little study on this issue. selinux avc log depends on audit subsystem. In /kernel/kernel/audit.c, some code has indicated that we may lost the records in five ways:

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*/

 

So is this the root-cause of my issue ? How can I modify kernel code to archieve my purpose or there already is a open/off switch to help me on giving all the logs in one time test ?

 

Thanks

Sincerely

Alan Xin

 

 

 

_______________________________________________
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.


_______________________________________________
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.

 


_______________________________________________
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.

 

_______________________________________________
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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux