* Give out all the avc logs in ome time @ 2015-05-05 2:06 Zhi Xin 2015-05-05 2:37 ` William Roberts 2015-05-05 12:41 ` Stephen Smalley 0 siblings, 2 replies; 20+ messages in thread From: Zhi Xin @ 2015-05-05 2:06 UTC (permalink / raw) To: selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 1982 bytes --] 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<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: 116<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] 117<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] 119<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit 120<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit 121<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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 [-- Attachment #2: Type: text/html, Size: 6911 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 2:06 Give out all the avc logs in ome time Zhi Xin @ 2015-05-05 2:37 ` William Roberts 2015-05-05 2:43 ` Zhi Xin 2015-05-05 5:55 ` Ravi Kumar 2015-05-05 12:41 ` Stephen Smalley 1 sibling, 2 replies; 20+ messages in thread From: William Roberts @ 2015-05-05 2:37 UTC (permalink / raw) To: Zhi Xin; +Cc: selinux [-- Attachment #1: Type: text/plain, Size: 2657 bytes --] 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@marvell.com> 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > [-- Attachment #2: Type: text/html, Size: 6304 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 2:37 ` William Roberts @ 2015-05-05 2:43 ` Zhi Xin 2015-05-05 2:51 ` William Roberts 2015-05-05 5:55 ` Ravi Kumar 1 sibling, 1 reply; 20+ messages in thread From: Zhi Xin @ 2015-05-05 2:43 UTC (permalink / raw) To: William Roberts; +Cc: selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 3127 bytes --] Hi William, In my experience, under permissive, we can indeed get more avc log than enforcing but it still cannot give all the deny log in one time. Usually, it require 2-3 round of policy adding for a complicated issue even under permissive. Any clue about this ? Thanks. Sincerely Alan Xin From: William Roberts [mailto:bill.c.roberts@gmail.com] Sent: 2015年5月5日 10:37 To: Zhi Xin Cc: selinux@tycho.nsa.gov Subject: Re: Give out all the avc logs in ome time 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@marvell.com<mailto:xinzhi@marvell.com>> 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<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: 116<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] 117<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] 119<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit 120<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit 121<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. [-- Attachment #2: Type: text/html, Size: 11798 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 2:43 ` Zhi Xin @ 2015-05-05 2:51 ` William Roberts 2015-05-05 3:00 ` William Roberts 0 siblings, 1 reply; 20+ messages in thread From: William Roberts @ 2015-05-05 2:51 UTC (permalink / raw) To: Zhi Xin; +Cc: selinux [-- Attachment #1: Type: text/plain, Size: 3675 bytes --] Outside of the fact that I see Linux will only print the first denial and permissive and perhaps your logs are rolling over or something like that I have no idea. SELinux and the audit framework in general will never miss a message with the exception of a full message queue or some exceptional case. Perhaps sds can shed some light on it that I'm not aware of On May 4, 2015 7:43 PM, "Zhi Xin" <xinzhi@marvell.com> wrote: > Hi William, > > > > In my experience, under permissive, we can indeed get more avc log than > enforcing but it still cannot give all the deny log in one time. Usually, > it require 2-3 round of policy adding for a complicated issue even under > permissive. > > > > Any clue about this ? > > > > Thanks. > > Sincerely > > Alan Xin > > > > *From:* William Roberts [mailto:bill.c.roberts@gmail.com] > *Sent:* 2015年5月5日 10:37 > *To:* Zhi Xin > *Cc:* selinux@tycho.nsa.gov > *Subject:* Re: Give out all the avc logs in ome time > > > > 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@marvell.com> 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > [-- Attachment #2: Type: text/html, Size: 10525 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 2:51 ` William Roberts @ 2015-05-05 3:00 ` William Roberts 0 siblings, 0 replies; 20+ messages in thread From: William Roberts @ 2015-05-05 3:00 UTC (permalink / raw) To: Zhi Xin; +Cc: selinux [-- Attachment #1: Type: text/plain, Size: 3284 bytes --] On May 4, 2015 7:51 PM, "William Roberts" <bill.c.roberts@gmail.com> wrote: > > Outside of the fact that I see Linux will Darn talk to text.. I see selinux only print the first denial and permissive and perhaps your logs are rolling over or something like that I have no idea. SELinux and the audit framework in general will never miss a message with the exception of a full message queue or some exceptional case. > > Perhaps sds can shed some light on it that I'm not aware of > > On May 4, 2015 7:43 PM, "Zhi Xin" <xinzhi@marvell.com> wrote: >> >> Hi William, >> >> >> >> In my experience, under permissive, we can indeed get more avc log than enforcing but it still cannot give all the deny log in one time. Usually, it require 2-3 round of policy adding for a complicated issue even under permissive. >> >> >> >> Any clue about this ? >> >> >> >> Thanks. >> >> Sincerely >> >> Alan Xin >> >> >> >> From: William Roberts [mailto:bill.c.roberts@gmail.com] >> Sent: 2015年5月5日 10:37 >> To: Zhi Xin >> Cc: selinux@tycho.nsa.gov >> Subject: Re: Give out all the avc logs in ome time >> >> >> >> 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@marvell.com> 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@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. [-- Attachment #2: Type: text/html, Size: 4638 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 2:37 ` William Roberts 2015-05-05 2:43 ` Zhi Xin @ 2015-05-05 5:55 ` Ravi Kumar 2015-05-05 7:32 ` Zhi Xin 1 sibling, 1 reply; 20+ messages in thread From: Ravi Kumar @ 2015-05-05 5:55 UTC (permalink / raw) To: William Roberts; +Cc: selinux [-- Attachment #1: Type: text/plain, Size: 3838 bytes --] 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@gmail.com> 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@marvell.com> 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: >> >> 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] >> >> 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] >> >> 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] >> >> 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit >> >> 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit >> >> 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to >> Selinux-request@tycho.nsa.gov. >> > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > [-- Attachment #2: Type: text/html, Size: 8256 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 5:55 ` Ravi Kumar @ 2015-05-05 7:32 ` Zhi Xin 2015-05-05 8:39 ` Gaurav Gangwar 0 siblings, 1 reply; 20+ messages in thread From: Zhi Xin @ 2015-05-05 7:32 UTC (permalink / raw) To: Ravi Kumar, William Roberts; +Cc: selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 4771 bytes --] 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@gmail.com] Sent: 2015年5月5日 13:56 To: William Roberts Cc: Zhi Xin; selinux@tycho.nsa.gov 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@gmail.com<mailto:bill.c.roberts@gmail.com>> 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@marvell.com<mailto:xinzhi@marvell.com>> 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<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: 116<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] 117<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] 119<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit 120<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit 121<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. [-- Attachment #2: Type: text/html, Size: 15542 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 7:32 ` Zhi Xin @ 2015-05-05 8:39 ` Gaurav Gangwar 2015-05-05 8:55 ` Zhi Xin 0 siblings, 1 reply; 20+ messages in thread From: Gaurav Gangwar @ 2015-05-05 8:39 UTC (permalink / raw) To: Zhi Xin; +Cc: selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 5356 bytes --] 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@marvell.com> 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@gmail.com] > *Sent:* 2015年5月5日 13:56 > *To:* William Roberts > *Cc:* Zhi Xin; selinux@tycho.nsa.gov > *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@gmail.com> > 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@marvell.com> 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > [-- Attachment #2: Type: text/html, Size: 14660 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 8:39 ` Gaurav Gangwar @ 2015-05-05 8:55 ` Zhi Xin 2015-05-05 13:41 ` Stephen Smalley 0 siblings, 1 reply; 20+ messages in thread From: Zhi Xin @ 2015-05-05 8:55 UTC (permalink / raw) To: Gaurav Gangwar; +Cc: selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 7375 bytes --] 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<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: 116<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] 117<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] 119<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit 120<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit 121<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#121>*/ Any comments on these two ? Thanks. Sincerely Alan Xin From: Gaurav Gangwar [mailto:gauravgangwaar@gmail.com] Sent: 2015年5月5日 16:39 To: Zhi Xin Cc: Ravi Kumar; William Roberts; selinux@tycho.nsa.gov 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@marvell.com<mailto:xinzhi@marvell.com>> 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@gmail.com<mailto:nxp.ravi@gmail.com>] Sent: 2015年5月5日 13:56 To: William Roberts Cc: Zhi Xin; selinux@tycho.nsa.gov<mailto:selinux@tycho.nsa.gov> 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@gmail.com<mailto:bill.c.roberts@gmail.com>> 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@marvell.com<mailto:xinzhi@marvell.com>> 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<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: 116<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] 117<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] 118<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] 119<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit 120<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit 121<http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>. [-- Attachment #2: Type: text/html, Size: 27273 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 8:55 ` Zhi Xin @ 2015-05-05 13:41 ` Stephen Smalley 2015-05-05 14:06 ` william.c.roberts 0 siblings, 1 reply; 20+ messages in thread From: Stephen Smalley @ 2015-05-05 13:41 UTC (permalink / raw) To: Zhi Xin, Gaurav Gangwar Cc: seandroid-list@tycho.nsa.gov, selinux@tycho.nsa.gov On 05/05/2015 04:55 AM, Zhi Xin wrote: > (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 ? No, that has nothing to do with auditing. Just the size of the cache. > (2) audit subsystem may drop some record when it’s satisfied with some > condition like > > > > /kernel/kernel/audit.c > > 115 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#121>*/ > > > > Any comments on these two ? Yes, one of the above cases is the most likely reason you are losing audit messages. You can set the audit_rate_limit to zero to disable ratelimiting of audit messages by removing the code from system/core/logd/libaudit.c that sets it. You could set the audit_backlog_limit to zero either by patching your kernel or by modifying logd to set it. You can patch your kernel to disable printk_ratelimit from being applied when sending audit messages to the kernel ring buffer. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 13:41 ` Stephen Smalley @ 2015-05-05 14:06 ` william.c.roberts 0 siblings, 0 replies; 20+ messages in thread From: william.c.roberts @ 2015-05-05 14:06 UTC (permalink / raw) To: Stephen Smalley; +Cc: seandroid-list@tycho.nsa.gov, selinux@tycho.nsa.gov > On 05/05/2015 04:55 AM, Zhi Xin wrote: >> (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 ? > > No, that has nothing to do with auditing. Just the size of the cache. > >> (2) audit subsystem may drop some record when it’s satisfied with some >> condition like >> >> >> >> /kernel/kernel/audit.c >> >> 115 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* >> Records can be lost in several ways: >> >> 116 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> >> 0) [suppressed in audit_alloc] >> >> 117 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> >> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] >> >> 118 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> >> 2) out of memory in audit_log_move [alloc_skb] >> >> 119 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> >> 3) suppressed due to audit_rate_limit >> >> 120 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> >> 4) suppressed due to audit_backlog_limit >> >> 121 >> <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#121>*/ >> >> >> >> Any comments on these two ? > > Yes, one of the above cases is the most likely reason you are losing > audit messages. You can set the audit_rate_limit to zero to disable > ratelimiting of audit messages by removing the code from > system/core/logd/libaudit.c that sets it. You could set the > audit_backlog_limit to zero either by patching your kernel or by > modifying logd to set it. You can patch your kernel to disable > printk_ratelimit from being applied when sending audit messages to the > kernel ring buffer. Its likely this, I normally patch this out on my kernel in the first few bring ups. I would start here if I were you. > > _______________________________________________ > Seandroid-list mailing list > Seandroid-list@tycho.nsa.gov > To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Seandroid-list-request@tycho.nsa.gov. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-05 2:06 Give out all the avc logs in ome time Zhi Xin 2015-05-05 2:37 ` William Roberts @ 2015-05-05 12:41 ` Stephen Smalley 2015-05-06 2:18 ` Zhi Xin 1 sibling, 1 reply; 20+ messages in thread From: Stephen Smalley @ 2015-05-05 12:41 UTC (permalink / raw) To: Zhi Xin, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov On 05/04/2015 10:06 PM, Zhi Xin 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#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 ? (cc'ing seandroid-list as you later mentioned that you are encountering this in the context of Android, although I don't know if it is truly specific to Android) Generally you should see audit_lost= log messages in dmesg if audit log messages were lost, although those are also subject to the printk ratelimit and could be suppressed. One thing you can try is to disable the audit ratelimit, which in Android is set by system/core/logd/libaudit.c. Just remove the AUDIT_STATUS_RATE_LIMIT flag from status.mask and don't bother setting status.rate_limit. We also carry a patch in our kernel branches for Nexus devices that disables the printk ratelimit for audit messages. e.g. https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-05 12:41 ` Stephen Smalley @ 2015-05-06 2:18 ` Zhi Xin 2015-05-06 12:19 ` Stephen Smalley 0 siblings, 1 reply; 20+ messages in thread From: Zhi Xin @ 2015-05-06 2:18 UTC (permalink / raw) To: Stephen Smalley, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov Hi Stephen, Thanks a lot for the suggestion. I will try them later. I have another question for this audit ratelimit. Why not always disable it ? Too much printk come up ? Sincerely Alan Xin -----Original Message----- From: Stephen Smalley [mailto:sds@tycho.nsa.gov] Sent: 2015年5月5日 20:42 To: Zhi Xin; selinux@tycho.nsa.gov Cc: seandroid-list@tycho.nsa.gov Subject: Re: Give out all the avc logs in ome time On 05/04/2015 10:06 PM, Zhi Xin 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 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#115>/* Records can be lost in several ways: > > 116 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#116> 0) [suppressed in audit_alloc] > > 117 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#117> 1) out of memory in audit_log_start [kmalloc of struct audit_buffer] > > 118 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#118> 2) out of memory in audit_log_move [alloc_skb] > > 119 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#119> 3) suppressed due to audit_rate_limit > > 120 <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audit.c#120> 4) suppressed due to audit_backlog_limit > > 121 > <http://10.38.120.31:8080/source/xref/pxa1928-lp5.0/kernel/kernel/audi > t.c#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 ? (cc'ing seandroid-list as you later mentioned that you are encountering this in the context of Android, although I don't know if it is truly specific to Android) Generally you should see audit_lost= log messages in dmesg if audit log messages were lost, although those are also subject to the printk ratelimit and could be suppressed. One thing you can try is to disable the audit ratelimit, which in Android is set by system/core/logd/libaudit.c. Just remove the AUDIT_STATUS_RATE_LIMIT flag from status.mask and don't bother setting status.rate_limit. We also carry a patch in our kernel branches for Nexus devices that disables the printk ratelimit for audit messages. e.g. https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-06 2:18 ` Zhi Xin @ 2015-05-06 12:19 ` Stephen Smalley 2015-05-07 3:18 ` Zhi Xin 0 siblings, 1 reply; 20+ messages in thread From: Stephen Smalley @ 2015-05-06 12:19 UTC (permalink / raw) To: Zhi Xin, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov On 05/05/2015 10:18 PM, Zhi Xin wrote: > Hi Stephen, > > Thanks a lot for the suggestion. I will try them later. I have another question for this audit ratelimit. Why not always disable it ? Too much printk come up ? In general, the printk and audit ratelimits are to prevent a denial of service (DOS) by flooding the system with too many messages/denials. In the case of Android, they started setting the audit ratelimit in logd (starting with 5.1.0) because of reported crashes that _might_ have been due to a large number of SELinux denials flooding the serial console and ultimately leading to a watchdog reset, although I am not sure if the exact cause was ever fully confirmed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-06 12:19 ` Stephen Smalley @ 2015-05-07 3:18 ` Zhi Xin 2015-05-07 4:02 ` William Roberts 2015-05-07 13:00 ` Stephen Smalley 0 siblings, 2 replies; 20+ messages in thread From: Zhi Xin @ 2015-05-07 3:18 UTC (permalink / raw) To: Stephen Smalley, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov Thanks a lot~ I have another question: in last email, you mentioned two ways to eliminate the ratelimit. (1) disable the audit ratelimit in logd by removing the AUDIT_STATUS_RATE_LIMIT flag from status.mask. (2) use the kernel https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27 I can understand how the kernel part work. But why do you still need to set a user space process like logd ? I mean the avc log is given by kernel. Why a user space process can affect its output ? Is is because the kernel log brought to user by this logd and if I want to disable audit ratelimit, I have to apply both of them ? I also wonder do we have a more simple mechanism like a open/off switch during runtime ? -----Original Message----- From: Stephen Smalley [mailto:sds@tycho.nsa.gov] Sent: 2015年5月6日 20:20 To: Zhi Xin; selinux@tycho.nsa.gov Cc: seandroid-list@tycho.nsa.gov Subject: Re: Give out all the avc logs in ome time On 05/05/2015 10:18 PM, Zhi Xin wrote: > Hi Stephen, > > Thanks a lot for the suggestion. I will try them later. I have another question for this audit ratelimit. Why not always disable it ? Too much printk come up ? In general, the printk and audit ratelimits are to prevent a denial of service (DOS) by flooding the system with too many messages/denials. In the case of Android, they started setting the audit ratelimit in logd (starting with 5.1.0) because of reported crashes that _might_ have been due to a large number of SELinux denials flooding the serial console and ultimately leading to a watchdog reset, although I am not sure if the exact cause was ever fully confirmed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-07 3:18 ` Zhi Xin @ 2015-05-07 4:02 ` William Roberts 2015-05-07 13:00 ` Stephen Smalley 1 sibling, 0 replies; 20+ messages in thread From: William Roberts @ 2015-05-07 4:02 UTC (permalink / raw) To: Zhi Xin Cc: seandroid-list@tycho.nsa.gov, Stephen Smalley, selinux@tycho.nsa.gov [-- Attachment #1: Type: text/plain, Size: 3081 bytes --] On Wed, May 6, 2015 at 8:18 PM, Zhi Xin <xinzhi@marvell.com> wrote: > Thanks a lot~ > > I have another question: in last email, you mentioned two ways to > eliminate the ratelimit. > > (1) disable the audit ratelimit in logd by removing the > AUDIT_STATUS_RATE_LIMIT flag from status.mask. > (2) use the kernel > https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27 > > I can understand how the kernel part work. But why do you still need to > set a user space process like logd ? I mean the avc log is given by kernel. > Why a user space process can affect its output ? Is is because the kernel > log brought to user by this logd and if I want to disable audit ratelimit, > I have to apply both of them ? > If their is no audit daemon (userspace) running, the audit subsystem of the kernel just simple printk's it to the kernel log. If their is a userspace daemon running, it sends it via the audit netlink to the userspace daemon, in this case logd. This is used in desktop distro's to send the logs over the network, or to disk. In logd, it merges it into the logcat stream. The audit subsystem was designed to be a flexible way to not only record information from the LSM's, but also other features. You can enable things like syscall auditing, in which more comprehensive records can be derived, as well as set filters and watches. > > I also wonder do we have a more simple mechanism like a open/off switch > during runtime ? > As in, we get denials messages or we don't? I think audit kernel has the capability to filter on records, but the userspace support was never brought into Android fully. When I had the auditd code on 4.3 base, some contributions were added to be able to set watches and filters IIRC. > > -----Original Message----- > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] > Sent: 2015年5月6日 20:20 > To: Zhi Xin; selinux@tycho.nsa.gov > Cc: seandroid-list@tycho.nsa.gov > Subject: Re: Give out all the avc logs in ome time > > On 05/05/2015 10:18 PM, Zhi Xin wrote: > > Hi Stephen, > > > > Thanks a lot for the suggestion. I will try them later. I have another > question for this audit ratelimit. Why not always disable it ? Too much > printk come up ? > > In general, the printk and audit ratelimits are to prevent a denial of > service (DOS) by flooding the system with too many messages/denials. In > the case of Android, they started setting the audit ratelimit in logd > (starting with 5.1.0) because of reported crashes that _might_ have been > due to a large number of SELinux denials flooding the serial console and > ultimately leading to a watchdog reset, although I am not sure if the exact > cause was ever fully confirmed. > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. -- Respectfully, William C Roberts [-- Attachment #2: Type: text/html, Size: 4178 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-07 3:18 ` Zhi Xin 2015-05-07 4:02 ` William Roberts @ 2015-05-07 13:00 ` Stephen Smalley 2015-05-08 8:46 ` Zhi Xin 1 sibling, 1 reply; 20+ messages in thread From: Stephen Smalley @ 2015-05-07 13:00 UTC (permalink / raw) To: Zhi Xin, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov On 05/06/2015 11:18 PM, Zhi Xin wrote: > Thanks a lot~ > > I have another question: in last email, you mentioned two ways to eliminate the ratelimit. > > (1) disable the audit ratelimit in logd by removing the AUDIT_STATUS_RATE_LIMIT flag from status.mask. > (2) use the kernel https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27 > > I can understand how the kernel part work. But why do you still need to set a user space process like logd ? I mean the avc log is given by kernel. Why a user space process can affect its output ? Is is because the kernel log brought to user by this logd and if I want to disable audit ratelimit, I have to apply both of them ? > > I also wonder do we have a more simple mechanism like a open/off switch during runtime ? Until logd (or auditd in Linux distributions like Fedora) starts running and registers itself to receive audit messages, the kernel logs the audit records directly via printk, and those calls are wrapped with printk_ratelimit checks to avoid a potential DOS. Once logd (or auditd) is registered to receive audit messages, the kernel sends audit records via the netlink audit socket to logd, and logd then writes them to /dev/kmsg (so that they are still available via dmesg; this differs from auditd behavior in Linux distributions) and also writes them to the logcat events and main log buffers (and this is obviously Android-specific). logd also grabs any previously logged audit records from dmesg and writes them to the logcat buffers so that even the audit records generated before logd started should be included in the logcat buffers, not just the ones generated afterward. The printk ratelimit is only relevant for the audit messages generated before logd is started, and for any warning/error messages logged via printk (e.g. printk limit exceeded, backlog limit exceeded, rate limit exceeded, out of memory...). It is not configurable and is always applied by the audit system when logging messages via printk. That's why we need a kernel patch to disable it. The audit ratelimit on the other hand is relevant for all audit messages, whether logged via printk or sent over the netlink audit socket, but is only set if logd explicitly sets it to something. And since logd only sets it if it is also registering itself to receive audit messages, then effectively the audit ratelimit only applies to audit messages sent over the netlink audit socket to logd. Not to messages logged before logd starts. I hadn't noticed this before, but in just looking at the logd code, I see that there are also a couple of system properties that you can set to alter its behavior wrt to audit: name type default description logd.auditd bool true Enable selinux audit daemon logd.auditd.dmesg bool true selinux audit messages duplicated and sent on to dmesg log So you could possibly disable logd's audit functionality altogether by setting logd.auditd to false and rebooting. At which point you would only be concerned with the printk ratelimit. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: Give out all the avc logs in ome time 2015-05-07 13:00 ` Stephen Smalley @ 2015-05-08 8:46 ` Zhi Xin 2015-05-08 12:57 ` Stephen Smalley 0 siblings, 1 reply; 20+ messages in thread From: Zhi Xin @ 2015-05-08 8:46 UTC (permalink / raw) To: Stephen Smalley, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov Thanks for details information! For the switch question, I get your point. logd.auditd is the switch of whether logd can record selinux audit log. But I'm looking for the switch of ratelimit. I mean, removing ratelimit is really helpful for selinux debugging, especially in bringup stage. But meanwhile, removing it just opens the gate for potential DOS. So should we have a simple command that can disable ratelimit during bringup debugging and enable it for release. Just like we can switch to permissive mode by setenforce 0. -----Original Message----- From: Stephen Smalley [mailto:sds@tycho.nsa.gov] Sent: 2015年5月7日 21:00 To: Zhi Xin; selinux@tycho.nsa.gov Cc: seandroid-list@tycho.nsa.gov Subject: Re: Give out all the avc logs in ome time On 05/06/2015 11:18 PM, Zhi Xin wrote: > Thanks a lot~ > > I have another question: in last email, you mentioned two ways to eliminate the ratelimit. > > (1) disable the audit ratelimit in logd by removing the AUDIT_STATUS_RATE_LIMIT flag from status.mask. > (2) use the kernel > https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42 > 929135babb1dbba272e27 > > I can understand how the kernel part work. But why do you still need to set a user space process like logd ? I mean the avc log is given by kernel. Why a user space process can affect its output ? Is is because the kernel log brought to user by this logd and if I want to disable audit ratelimit, I have to apply both of them ? > > I also wonder do we have a more simple mechanism like a open/off switch during runtime ? Until logd (or auditd in Linux distributions like Fedora) starts running and registers itself to receive audit messages, the kernel logs the audit records directly via printk, and those calls are wrapped with printk_ratelimit checks to avoid a potential DOS. Once logd (or auditd) is registered to receive audit messages, the kernel sends audit records via the netlink audit socket to logd, and logd then writes them to /dev/kmsg (so that they are still available via dmesg; this differs from auditd behavior in Linux distributions) and also writes them to the logcat events and main log buffers (and this is obviously Android-specific). logd also grabs any previously logged audit records from dmesg and writes them to the logcat buffers so that even the audit records generated before logd started should be included in the logcat buffers, not just the ones generated afterward. The printk ratelimit is only relevant for the audit messages generated before logd is started, and for any warning/error messages logged via printk (e.g. printk limit exceeded, backlog limit exceeded, rate limit exceeded, out of memory...). It is not configurable and is always applied by the audit system when logging messages via printk. That's why we need a kernel patch to disable it. The audit ratelimit on the other hand is relevant for all audit messages, whether logged via printk or sent over the netlink audit socket, but is only set if logd explicitly sets it to something. And since logd only sets it if it is also registering itself to receive audit messages, then effectively the audit ratelimit only applies to audit messages sent over the netlink audit socket to logd. Not to messages logged before logd starts. I hadn't noticed this before, but in just looking at the logd code, I see that there are also a couple of system properties that you can set to alter its behavior wrt to audit: name type default description logd.auditd bool true Enable selinux audit daemon logd.auditd.dmesg bool true selinux audit messages duplicated and sent on to dmesg log So you could possibly disable logd's audit functionality altogether by setting logd.auditd to false and rebooting. At which point you would only be concerned with the printk ratelimit. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-08 8:46 ` Zhi Xin @ 2015-05-08 12:57 ` Stephen Smalley 2015-05-08 13:31 ` Paul Moore 0 siblings, 1 reply; 20+ messages in thread From: Stephen Smalley @ 2015-05-08 12:57 UTC (permalink / raw) To: Zhi Xin, selinux@tycho.nsa.gov; +Cc: seandroid-list@tycho.nsa.gov On 05/08/2015 04:46 AM, Zhi Xin wrote: > Thanks for details information! > > For the switch question, I get your point. logd.auditd is the switch of whether logd can record selinux audit log. But I'm looking for the switch of ratelimit. I mean, removing ratelimit is really helpful for selinux debugging, especially in bringup stage. But meanwhile, removing it just opens the gate for potential DOS. So should we have a simple command that can disable ratelimit during bringup debugging and enable it for release. Just like we can switch to permissive mode by setenforce 0. For this, you'd need an audit boot parameter in order to fully disable the printk ratelimit even before logd starts. So it would require a kernel patch to define such a parameter. There are existing audit boot parameters for enabling/disabling audit (audit=0|1) and for setting the backlog limit (audit_backlog_limit=N). Those are defined in kernel/audit.c via __setup() calls. You could add an audit_ratelimit=N and/or an audit_printk_ratelimit=0|1 boot parameters. Kernel audit patches would need to go to the audit maintainers (see the MAINTAINERS entry for AUDIT) and the linux-audit@redhat.com mailing list, subscribe via: https://www.redhat.com/mailman/listinfo/linux-audit Once the kernel audit patch was accepted, then you could submit it to kernel/common in AOSP and also submit a patch for logd so that it would check /proc/cmdline for the parameter and if set, honor it rather than overriding it. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Give out all the avc logs in ome time 2015-05-08 12:57 ` Stephen Smalley @ 2015-05-08 13:31 ` Paul Moore 0 siblings, 0 replies; 20+ messages in thread From: Paul Moore @ 2015-05-08 13:31 UTC (permalink / raw) To: Stephen Smalley; +Cc: seandroid-list@tycho.nsa.gov, selinux@tycho.nsa.gov On Fri, May 8, 2015 at 8:57 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > On 05/08/2015 04:46 AM, Zhi Xin wrote: >> Thanks for details information! >> >> For the switch question, I get your point. logd.auditd is the switch of whether logd can record selinux audit log. But I'm looking for the switch of ratelimit. I mean, removing ratelimit is really helpful for selinux debugging, especially in bringup stage. But meanwhile, removing it just opens the gate for potential DOS. So should we have a simple command that can disable ratelimit during bringup debugging and enable it for release. Just like we can switch to permissive mode by setenforce 0. > > For this, you'd need an audit boot parameter in order to fully disable > the printk ratelimit even before logd starts. So it would require a > kernel patch to define such a parameter. There are existing audit boot > parameters for enabling/disabling audit (audit=0|1) and for setting the > backlog limit (audit_backlog_limit=N). Those are defined in > kernel/audit.c via __setup() calls. You could add an audit_ratelimit=N > and/or an audit_printk_ratelimit=0|1 boot parameters. For the record, I don't have a problem with accepting a patch that added a boot parameter to control the audit ratelimit. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-05-08 13:31 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-05 2:06 Give out all the avc logs in ome time Zhi Xin 2015-05-05 2:37 ` William Roberts 2015-05-05 2:43 ` Zhi Xin 2015-05-05 2:51 ` William Roberts 2015-05-05 3:00 ` William Roberts 2015-05-05 5:55 ` Ravi Kumar 2015-05-05 7:32 ` Zhi Xin 2015-05-05 8:39 ` Gaurav Gangwar 2015-05-05 8:55 ` Zhi Xin 2015-05-05 13:41 ` Stephen Smalley 2015-05-05 14:06 ` william.c.roberts 2015-05-05 12:41 ` Stephen Smalley 2015-05-06 2:18 ` Zhi Xin 2015-05-06 12:19 ` Stephen Smalley 2015-05-07 3:18 ` Zhi Xin 2015-05-07 4:02 ` William Roberts 2015-05-07 13:00 ` Stephen Smalley 2015-05-08 8:46 ` Zhi Xin 2015-05-08 12:57 ` Stephen Smalley 2015-05-08 13:31 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.