Thanks, I pulled down the update grouper policies and updated the device with
them. I'm seeing a few more puzzling denials that I was hoping you could shed
some light on.
1) audit(1364517929.121:116): avc: denied { write } for pid=7872
comm="m.amazon.kindle"
path=2F6465762F6173686D656D2F6C696265787061744B52462E736F202864656C6574656429
dev=tmpfs ino=16790 scontext=u:r:untrusted_app:s0:c42,c256
tcontext=u:object_r:untrusted_app_tmpfs:s0:c42,c256 tclass=file
This is similar to what Joshua Brindle saw last October
(http://www.mail-archive.com/seandroid-list@tycho.nsa.gov/msg00141.html). At
the time, you said "That becomes another means of write+execute to the same
file/memory. It would be preferable if we could get it into a different type."
I don't quite understand what you mean by that. Can you please clarify?
Also, what is the actual directory that tmpfs represents, and how would I
determine that from looking at the policy files (I see it in te_macros, but I
don't see how it's related to a physical directory).
2) audit(1364517725.581:115): avc: denied { open } for pid=125
comm="debuggerd" name="libCore.so" dev=mmcblk0p9 ino=217299
scontext=u:r:debuggerd:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
The app (air.WatchESPN) crashes, and it appears that debuggerd is attempting to
open a library in the app's lib directory:
shell@android:/data/data/air.WatchESPN/lib # ls
libCore.so
I think this happening when debuggerd attempts to load the symbol table for
libCore.so
The call graph is: dump_backtrace -> load_ptrace_context ->
load_ptrace_map_info_data -> load_symbol_table
3) audit(1364518882.161:133): avc: denied { write } for pid=241
comm="SurfaceFlinger" name="aggressiveness" dev=sysfs ino=3549
scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:sysfs:s0 tclass=file
This one occurs when com.fingersoft.cartooncamera is running, and I'm not
entirely sure what is going on.
Thanks for the information,
-Ryan
-----Original Message-----
From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
Sent: Tuesday, March 26, 2013 4:25 PM
To: Persaud, Ryan K.
Cc: seandroid-list@tycho.nsa.gov
Subject: Re: /sys/devices/system/cpu denials
On 03/26/2013 04:10 PM, Persaud, Ryan K. wrote:
> Hello,
>
> We ran our testing framework with the seandroid-4.2 branch on a Nexus 7
> tablet against 126 popular free apps from the Google Play store. A
> denial that occurred for 11 applications can be seen below (1). Based on
> some investigation, it looks like these applications are trying to
> determine the number of CPU cores on a device
> (http://stackoverflow.com/questions/7962155/how-can-you-detect-a-dual-core-cpu-on-an-android-device-from-code).
> Given that it appears that a not insignificant number of applications
> regularly examine /sys/devices/system/cpu, should a policy be added to
> allow this? As far as I can tell, none of the applications crashed due
> to the denial, but I'm not sure what the performance implications are.
>
> The same denial (2) also occurred 23 times for ActivityManager during
> testing. Our investigation of the ActivityManager sources and
> documentation did not lead to any obvious culprits. Any idea why
> ActivityManager would be also be causing these denials? Is it possible
> that the denials are being misattributed to the ActivityManager? Once
> testing stopped, and the device was idle, the ActivityManager denials
> ceased.
>
> 1)audit(1363573739.308:52): avc: denied { search } for pid=7762
> comm="t.cartooncamera" name="cpu" dev=sysfs ino=26
> scontext=u:r:untrusted_app:s0:c44,c256
> tcontext=u:object_r:sysfs_devices_system_cpu:s0 tclass=dir
>
> 2)audit(1363572507.738:40): avc: denied { search } for pid=495
> comm="ActivityManager" name="cpu" dev=sysfs ino=26
> scontext=u:r:system:s0 tcontext=u:object_r:sysfs_devices_system_cpu:s0
> tclass=dir
>
> Thanks for the information,
I think these should be resolved by recent changes to the group project.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
