CTS failure on SEAndroid Galaxy Nexus

CTS failure on SEAndroid Galaxy Nexus

[Subramani Venkatesh]

Hi,
Trying to execute CTS on SEAndroid with security enforce, but I am not
successful getting it working, it crashes at the very beginning with
an exeception, is anyone else seeing the same issue?

W/ProcessStats(  207): Skipping unknown process pid 1233
D/AndroidRuntime( 1246):
D/AndroidRuntime( 1246): >>>>>> AndroidRuntime START
com.android.internal.os.RuntimeInit <<<<<<
D/AndroidRuntime( 1246): CheckJNI is OFF
W/dalvikvm( 1246): Exception Ljava/lang/NullPointerException; thrown
while initializing Ljava/lang/System;
W/dalvikvm( 1246): Exception Ljava/lang/ExceptionInInitializerError;
thrown while initializing Ljava/lang/ClassLoader$SystemClassLoader;
W/dalvikvm( 1246): WARNING: system class loader is NULL (setting main ctxt)
W/dalvikvm( 1246): Warning: tracked references remain post-initialization
W/dalvikvm( 1246): MAIN reference table (0x170be90) dump:
W/dalvikvm( 1246):   Last 1 entries (of 1):
E/dalvikvm( 1246): Class lookup Ljava/lang/Daemons; attempted with
exception pending
W/dalvikvm( 1246): Pending exception is:
I/dalvikvm( 1246): java.lang.ExceptionInInitializerError:
I/dalvikvm( 1246):      at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:125)
I/dalvikvm( 1246):      at dalvik.system.NativeStart.main(Native Method)
I/dalvikvm( 1246): Caused by:
I/dalvikvm( 1246): java.lang.ExceptionInInitializerError:
I/dalvikvm( 1246):      at
java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:100)
I/dalvikvm( 1246):      at java.lang.ClassLoader.access$000(ClassLoader.java:65)
I/dalvikvm( 1246):      at
java.lang.ClassLoader$SystemClassLoader.<clinit>(ClassLoader.java:81)
I/dalvikvm( 1246):      at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:125)
I/dalvikvm( 1246):      at dalvik.system.NativeStart.main(Native Method)
I/dalvikvm( 1246): Caused by:
I/dalvikvm( 1246): java.lang.NullPointerException:
I/dalvikvm( 1246):      at java.util.Hashtable.put(Hashtable.java:365)
I/dalvikvm( 1246):      at
java.lang.System.initSystemProperties(System.java:286)
I/dalvikvm( 1246):      at java.lang.System.getProperties(System.java:260)
I/dalvikvm( 1246):      at java.lang.System.getProperty(System.java:425)
I/dalvikvm( 1246):      at java.lang.System.getProperty(System.java:406)
I/dalvikvm( 1246):      at java.lang.System.<clinit>(System.java:90)
I/dalvikvm( 1246):      at
java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:100)
I/dalvikvm( 1246):      at java.lang.ClassLoader.access$000(ClassLoader.java:65)
I/dalvikvm( 1246):      at
java.lang.ClassLoader$SystemClassLoader.<clinit>(ClassLoader.java:81)
I/dalvikvm( 1246):      at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:125)
I/dalvikvm( 1246):      at dalvik.system.NativeStart.main(Native Method)


Regards,
Subbu

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Stephen Smalley]

On Wed, 2012-03-07 at 08:18 -0500, Subramani Venkatesh wrote:
> Hi,
> Trying to execute CTS on SEAndroid with security enforce, but I am not
> successful getting it working, it crashes at the very beginning with
> an exeception, is anyone else seeing the same issue?

First, did you make sure that you had no avc messages before going into
enforcing mode and even trying to run the CTS?  adb shell dmesg | grep
avc should yield no output.

Second, make sure you can run the CTS in permissive mode without any
difficulties as your baseline.

Third, make sure you enable the android_cts policy boolean before
running the CTS.  If you have configured the CTS to not reboot the
device (set maxTestCount to -1 in repository/host_config.xml), then you
can just do this once via adb shell su 0 setsebool android_cts=1.
Otherwise, if you want to allow periodic reboots during the CTS, you
need to add setsebool android_cts=1 and setenforce 1 to your init.rc or
init.<board>.rc file so that it happens on each boot.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Subramani Venkatesh]

Hi Stephen,

Thanks for the response, my comments are inlined

On Wed, Mar 7, 2012 at 8:36 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2012-03-07 at 08:18 -0500, Subramani Venkatesh wrote:
>> Hi,
>> Trying to execute CTS on SEAndroid with security enforce, but I am not
>> successful getting it working, it crashes at the very beginning with
>> an exeception, is anyone else seeing the same issue?
>
> First, did you make sure that you had no avc messages before going into
> enforcing mode and even trying to run the CTS?  adb shell dmesg | grep
> avc should yield no output.
<Subbu>: I fixed most of it, they were couple of them missing, I will
fix them and try again.
>
> Second, make sure you can run the CTS in permissive mode without any
> difficulties as your baseline.
<Subbu>: Yes CTS executes in permissive mode without any issues.
>
> Third, make sure you enable the android_cts policy boolean before
> running the CTS.  If you have configured the CTS to not reboot the
> device (set maxTestCount to -1 in repository/host_config.xml), then you
> can just do this once via adb shell su 0 setsebool android_cts=1.
> Otherwise, if you want to allow periodic reboots during the CTS, you
> need to add setsebool android_cts=1 and setenforce 1 to your init.rc or
> init.<board>.rc file so that it happens on each boot.
<Subbu>: I did enable android_cts_policy boolean, I shall try changed
my init.rc file to setenforce 1 all the time.

>
> --
> Stephen Smalley
> National Security Agency
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Stephen Smalley]

On Wed, 2012-03-07 at 08:57 -0500, Subramani Venkatesh wrote:
> Hi Stephen,
> 
> Thanks for the response, my comments are inlined
> 
> On Wed, Mar 7, 2012 at 8:36 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2012-03-07 at 08:18 -0500, Subramani Venkatesh wrote:
> >> Hi,
> >> Trying to execute CTS on SEAndroid with security enforce, but I am not
> >> successful getting it working, it crashes at the very beginning with
> >> an exeception, is anyone else seeing the same issue?
> >
> > First, did you make sure that you had no avc messages before going into
> > enforcing mode and even trying to run the CTS?  adb shell dmesg | grep
> > avc should yield no output.
> <Subbu>: I fixed most of it, they were couple of them missing, I will
> fix them and try again.
> >
> > Second, make sure you can run the CTS in permissive mode without any
> > difficulties as your baseline.
> <Subbu>: Yes CTS executes in permissive mode without any issues.
> >
> > Third, make sure you enable the android_cts policy boolean before
> > running the CTS.  If you have configured the CTS to not reboot the
> > device (set maxTestCount to -1 in repository/host_config.xml), then you
> > can just do this once via adb shell su 0 setsebool android_cts=1.
> > Otherwise, if you want to allow periodic reboots during the CTS, you
> > need to add setsebool android_cts=1 and setenforce 1 to your init.rc or
> > init.<board>.rc file so that it happens on each boot.
> <Subbu>: I did enable android_cts_policy boolean, I shall try changed
> my init.rc file to setenforce 1 all the time.

If you can run the CTS while in permissive mode, then you should do that
again (leaving it in permissive mode, with android_cts=1) and collect up
the denials.

adb shell su 0 cat /proc/kmsg > dmesg.txt

You can then add any necessary rules to cts.te under the boolean.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Stephen Smalley]

On Wed, 2012-03-07 at 09:06 -0500, Stephen Smalley wrote:
> On Wed, 2012-03-07 at 08:57 -0500, Subramani Venkatesh wrote:
> > Hi Stephen,
> > 
> > Thanks for the response, my comments are inlined
> > 
> > On Wed, Mar 7, 2012 at 8:36 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > On Wed, 2012-03-07 at 08:18 -0500, Subramani Venkatesh wrote:
> > >> Hi,
> > >> Trying to execute CTS on SEAndroid with security enforce, but I am not
> > >> successful getting it working, it crashes at the very beginning with
> > >> an exeception, is anyone else seeing the same issue?
> > >
> > > First, did you make sure that you had no avc messages before going into
> > > enforcing mode and even trying to run the CTS?  adb shell dmesg | grep
> > > avc should yield no output.
> > <Subbu>: I fixed most of it, they were couple of them missing, I will
> > fix them and try again.
> > >
> > > Second, make sure you can run the CTS in permissive mode without any
> > > difficulties as your baseline.
> > <Subbu>: Yes CTS executes in permissive mode without any issues.
> > >
> > > Third, make sure you enable the android_cts policy boolean before
> > > running the CTS.  If you have configured the CTS to not reboot the
> > > device (set maxTestCount to -1 in repository/host_config.xml), then you
> > > can just do this once via adb shell su 0 setsebool android_cts=1.
> > > Otherwise, if you want to allow periodic reboots during the CTS, you
> > > need to add setsebool android_cts=1 and setenforce 1 to your init.rc or
> > > init.<board>.rc file so that it happens on each boot.
> > <Subbu>: I did enable android_cts_policy boolean, I shall try changed
> > my init.rc file to setenforce 1 all the time.
> 
> If you can run the CTS while in permissive mode, then you should do that
> again (leaving it in permissive mode, with android_cts=1) and collect up
> the denials.
> 
> adb shell su 0 cat /proc/kmsg > dmesg.txt
> 
> You can then add any necessary rules to cts.te under the boolean.

Just tried this myself, and I see that we'll need to make a few
adjustments to policy for the current CTS.  Some of those will be made
unconditionally outside of the android_cts boolean, while others are
really only appropriate under test conditions and not production use.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Stephen Smalley]

On Wed, 2012-03-07 at 09:40 -0500, Stephen Smalley wrote:
> Just tried this myself, and I see that we'll need to make a few
> adjustments to policy for the current CTS.  Some of those will be made
> unconditionally outside of the android_cts boolean, while others are
> really only appropriate under test conditions and not production use.

I tracked down a subtle issue that was being hidden by a dontaudit rule
in the policy, and updated sepolicy for various denials that I saw in
getting the latest CTS started.  No guarantees that it will run all the
way through, but it certainly gets started now.  Prior to running the
CTS, I do the following:

adb shell su 0 setsebool android_cts=1
adb shell su 0 setenforce 1
adb shell su 0 cat /proc/kmsg > dmesg.txt &
adb logcat *:E > log.txt &

Later you can do something like the following to reduce dmesg.txt to
just the unique allow rules for easy review, although you would
typically evaluate each one to decide whether it should be generalized
(e.g. written in terms of a type attribute or using a macro), changed to
introduce a new domain or type, or replaced with a dontaudit rule.

audit2allow -p out/target/product/<device>/root/sepolicy.24 < dmesg.txt

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Subramani Venkatesh]

Hi Stephen,
I collected some log about AVC denial running CTS in permissive mode,
I am seeing most of the calls being denied on binder( receive and
call), and all CTS apps are under untrusted_app domain, though I can
add the fix in cts.te to continue execution CTS, I am concerned in
future if someone enables android_cts and still can install some
untrusted app( May be not part of CTS).  How does this work? or is
android_cts is for only development platform?

Here is the log

<5>[  505.486053] type=1400 audit(1331221519.312:4): avc:  denied  {
receive } for  pid=462 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  506.026611] type=1400 audit(1331221519.851:5): avc:  denied  {
receive } for  pid=109 comm="servicemanager"
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:radio:s0 tclass=binder
<5>[  506.027191] type=1400 audit(1331221519.851:6): avc:  denied  {
call } for  pid=1086 comm="eInfoInstrument"
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:radio:s0 tclass=binder
<5>[  519.138549] type=1400 audit(1331221532.960:7): avc:  denied  {
use } for  pid=1093 comm="df"
path=2F6465762F5F5F70726F706572746965735F5F202864656C6574656429
dev=tmpfs ino=1041 scontext=u:r:untrusted_app:s0:c41
tcontext=u:r:kernel:s0 tclass=fd
<5>[  519.138702] type=1400 audit(1331221532.960:8): avc:  denied  {
read } for  pid=1093 comm="df"
path=2F6465762F5F5F70726F706572746965735F5F202864656C6574656429
dev=tmpfs ino=1041 scontext=u:r:untrusted_app:s0:c41
tcontext=u:object_r:tmpfs:s0 tclass=file
<5>[  565.803955] type=1400 audit(1331221579.632:9): avc:  denied  {
receive } for  pid=397 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  566.417846] type=1400 audit(1331221580.242:10): avc:  denied  {
call } for  pid=1207 comm="ationTestRunner"
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  576.880157] type=1400 audit(1331221590.703:11): avc:  denied  {
receive } for  pid=384 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c40 tcontext=u:r:shell:s0 tclass=binder
<5>[  576.943878] type=1400 audit(1331221590.765:12): avc:  denied  {
call } for  pid=1306 comm="ationTestRunner"
scontext=u:r:untrusted_app:s0:c40 tcontext=u:r:shell:s0 tclass=binder
<5>[  584.875183] type=1400 audit(1331221598.703:13): avc:  denied  {
receive } for  pid=462 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  584.936218] type=1400 audit(1331221598.757:14): avc:  denied  {
call } for  pid=1376 comm="onCtsTestRunner"
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  588.049377] type=1400 audit(1331221601.875:15): avc:  denied  {
call } for  pid=1376 comm="onCtsTestRunner"
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  597.659912] type=1400 audit(1331221611.484:16): avc:  denied  {
receive } for  pid=217 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c41 tcontext=u:r:shell:s0 tclass=binder
<5>[  618.888977] type=1400 audit(1331221632.710:17): avc:  denied  {
receive } for  pid=218 comm=42696E646572205468726561642023
scontext=u:r:untrusted_app:s0:c38 tcontext=u:r:shell:s0 tclass=binder
<5>[  618.962188] type=1400 audit(1331221632.789:18): avc:  denied  {
call } for  pid=1953 comm="ationTestRunner"
scontext=u:r:untrusted_app:s0:c38 tcontext=u:r:shell:s0 tclass=binder


Regards,
Subbu

On Wed, Mar 7, 2012 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2012-03-07 at 09:40 -0500, Stephen Smalley wrote:
>> Just tried this myself, and I see that we'll need to make a few
>> adjustments to policy for the current CTS.  Some of those will be made
>> unconditionally outside of the android_cts boolean, while others are
>> really only appropriate under test conditions and not production use.
>
> I tracked down a subtle issue that was being hidden by a dontaudit rule
> in the policy, and updated sepolicy for various denials that I saw in
> getting the latest CTS started.  No guarantees that it will run all the
> way through, but it certainly gets started now.  Prior to running the
> CTS, I do the following:
>
> adb shell su 0 setsebool android_cts=1
> adb shell su 0 setenforce 1
> adb shell su 0 cat /proc/kmsg > dmesg.txt &
> adb logcat *:E > log.txt &
>
> Later you can do something like the following to reduce dmesg.txt to
> just the unique allow rules for easy review, although you would
> typically evaluate each one to decide whether it should be generalized
> (e.g. written in terms of a type attribute or using a macro), changed to
> introduce a new domain or type, or replaced with a dontaudit rule.
>
> audit2allow -p out/target/product/<device>/root/sepolicy.24 < dmesg.txt
>
> --
> Stephen Smalley
> National Security Agency
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Stephen Smalley]

On Thu, 2012-03-08 at 11:09 -0500, Subramani Venkatesh wrote:
> Hi Stephen,
> I collected some log about AVC denial running CTS in permissive mode,
> I am seeing most of the calls being denied on binder( receive and
> call), and all CTS apps are under untrusted_app domain, though I can
> add the fix in cts.te to continue execution CTS, I am concerned in
> future if someone enables android_cts and still can install some
> untrusted app( May be not part of CTS).  How does this work? or is
> android_cts is for only development platform?

Did you update to our latest policy?  Make sure you use the latest
local_manifest.xml file,
http://selinuxproject.org/~seandroid/local_manifest.xml
so that you use our sepolicy project and not the (not yet updated) AOSP
one.  Then run repo sync -j1 with that local_manifest.xml file in
your .repo subdirectory.

The denials you listed should already be fixed with our latest tree.
I'm still investigating some other denials during CTS execution.

The concept of the android_cts boolean is to allow certain permissions
for the CTS instrumentation on the device that aren't
necessary/desirable for production devices.  So it would only be enabled
when running the CTS normally.

An alternative would be to assign the CTS packages specific app domains
by specifying their package names in seapp_contexts and defining a
cts_app domain in the policy with the requisite permissions.  However,
as package names are arbitrary and there is no namespace control over
who can use what names, that would be less safe in practice - any third
party app could use the same name.  That only really works for system
apps where you know that the package is pre-installed.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Subramani Venkatesh]

Thanks Stephen, Thought I have latest local_manifest,  I had to sync
this morning, seeing new changes, will let you know how it goes.

-Subbu

On Thu, Mar 8, 2012 at 11:18 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2012-03-08 at 11:09 -0500, Subramani Venkatesh wrote:
>> Hi Stephen,
>> I collected some log about AVC denial running CTS in permissive mode,
>> I am seeing most of the calls being denied on binder( receive and
>> call), and all CTS apps are under untrusted_app domain, though I can
>> add the fix in cts.te to continue da CTS, I am concerned in
>> future if someone enables android_cts and still can install some
>> untrusted app( May be not part of CTS).  How does this work? or is
>> android_cts is for only development platform?
>
> Did you update to our latest policy?  Make sure you use the latest
> local_manifest.xml file,
> http://selinuxproject.org/~seandroid/local_manifest.xml
> so that you use our sepolicy project and not the (not yet updated) AOSP
> one.  Then run repo sync -j1 with that local_manifest.xml file in
> your .repo subdirectory.
>
> The denials you listed should already be fixed with our latest tree.
> I'm still investigating some other denials during CTS execution.
>
> The concept of the android_cts boolean is to allow certain permissions
> for the CTS instrumentation on the device that aren't
> necessary/desirable for production devices.  So it would only be enabled
> when running the CTS normally.
>
> An alternative would be to assign the CTS packages specific app domains
> by specifying their package names in seapp_contexts and defining a
> cts_app domain in the policy with the requisite permissions.  However,
> as package names are arbitrary and there is no namespace control over
> who can use what names, that would be less safe in practice - any third
> party app could use the same name.  That only really works for system
> apps where you know that the package is pre-installed.
>
> --
> Stephen Smalley
> National Security Agency
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CTS failure on SEAndroid Galaxy Nexus

[Fred Aguirre]

[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]

List

On Wed, Mar 7, 2012 at 6:40 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Wed, 2012-03-07 at 09:06 -0500, Stephen Smalley wrote:
> > On Wed, 2012-03-07 at 08:57 -0500, Subramani Venkatesh wrote:
> > > Hi Stephen,
> > >
> > > Thanks for the response, my comments are inlined
> > >
> > > On Wed, Mar 7, 2012 at 8:36 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > > > On Wed, 2012-03-07 at 08:18 -0500, Subramani Venkatesh wrote:
> > > >> Hi,
> > > >> Trying to execute CTS on SEAndroid with security enforce, but I am
> not
> > > >> successful getting it working, it crashes at the very beginning with
> > > >> an exeception, is anyone else seeing the same issue?
> > > >
> > > > First, did you make sure that you had no avc messages before going
> into
> > > > enforcing mode and even trying to run the CTS?  adb shell dmesg |
> grep
> > > > avc should yield no output.
> > > <Subbu>: I fixed most of it, they were couple of them missing, I will
> > > fix them and try again.
> > > >
> > > > Second, make sure you can run the CTS in permissive mode without any
> > > > difficulties as your baseline.
> > > <Subbu>: Yes CTS executes in permissive mode without any issues.
> > > >
> > > > Third, make sure you enable the android_cts policy boolean before
> > > > running the CTS.  If you have configured the CTS to not reboot the
> > > > device (set maxTestCount to -1 in repository/host_config.xml), then
> you
> > > > can just do this once via adb shell su 0 setsebool android_cts=1.
> > > > Otherwise, if you want to allow periodic reboots during the CTS, you
> > > > need to add setsebool android_cts=1 and setenforce 1 to your init.rc
> or
> > > > init.<board>.rc file so that it happens on each boot.
> > > <Subbu>: I did enable android_cts_policy boolean, I shall try changed
> > > my init.rc file to setenforce 1 all the time.
> >
> > If you can run the CTS while in permissive mode, then you should do that
> > again (leaving it in permissive mode, with android_cts=1) and collect up
> > the denials.
> >
> > adb shell su 0 cat /proc/kmsg > dmesg.txt
> >
> > You can then add any necessary rules to cts.te under the boolean.
>
> Just tried this myself, and I see that we'll need to make a few
> adjustments to policy for the current CTS.  Some of those will be made
> unconditionally outside of the android_cts boolean, while others are
> really only appropriate under test conditions and not production use.
>
> --
> Stephen Smalley
> National Security Agency
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith
> the words "unsubscribe selinux" without quotes as the message.
>

[-- Attachment #2: Type: text/html, Size: 3630 bytes --]