Give out all the avc logs in ome time

Give out all the avc logs in ome time

[Zhi Xin]

[-- 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 --]

Re: Give out all the avc logs in ome time

[William Roberts]

[-- 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 --]

RE: Give out all the avc logs in ome time

[Zhi Xin]

[-- 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 --]

RE: Give out all the avc logs in ome time

[William Roberts]

[-- 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 --]

RE: Give out all the avc logs in ome time

[William Roberts]

[-- 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 --]

Re: Give out all the avc logs in ome time

[Ravi Kumar]

[-- 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 --]

RE: Give out all the avc logs in ome time

[Zhi Xin]

[-- 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 --]

Re: Give out all the avc logs in ome time

[Gaurav Gangwar]

[-- 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 --]

RE: Give out all the avc logs in ome time

[Zhi Xin]

[-- 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 --]

Re: Give out all the avc logs in ome time

[Stephen Smalley]

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

Re: Give out all the avc logs in ome time

[Stephen Smalley]

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.

Re: Give out all the avc logs in ome time

[william.c.roberts]

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

RE: Give out all the avc logs in ome time

[Zhi Xin]

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

Re: Give out all the avc logs in ome time

[Stephen Smalley]

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.

RE: Give out all the avc logs in ome time

[Zhi Xin]

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.

Re: Give out all the avc logs in ome time

[William Roberts]

[-- 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 --]

Re: Give out all the avc logs in ome time

[Stephen Smalley]

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.

RE: Give out all the avc logs in ome time

[Zhi Xin]

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.

Re: Give out all the avc logs in ome time

[Stephen Smalley]

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.

Re: Give out all the avc logs in ome time

[Paul Moore]

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