On 03/29/2013 05:35 PM, Persaud, Ryan K. wrote:
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).
Passing this through ausearch -i (after tweaking it by hand to include
the type=AVC msg= prefix expected by ausearch), we can decode the pathname:
type=AVC msg=audit(03/28/2013 20:45:29.121:116) : avc: denied { write
} for pid=7872 comm=m.amazon.kindle path=/dev/ashmem/libexpatKRF.so
(deleted) dev=tmpfs ino=16790 scontext=u:r:untrusted_app:s0:c42,c256
tcontext=u:object_r:untrusted_app_tmpfs:s0:c42,c256 tclass=file
The path was hex encoded by the kernel because it contained whitespace
characters - the " (deleted)" suffix, which was added automatically by
the kernel when generating a pathname for audit because the underlying
tmpfs file is unlinked. The "/dev/ashmem/" prefix tells you that it is
an ashmem region (which are backed by tmpfs files). The libexpatKRF.so
is the ashmem region name provided by userspace, presumably derived from
the asset file name (see below).
Looking around a bit, I think this is a case of a native code library
being packaged as an asset of the .jar file and manually extracted by
the app rather than being packaged as a lib and extracted by the system.
See for example:
http://blog.crittercism.com/2012/08/22/packaging-android-libraries-with-native-code/
I suspect that we just have to allow it if we want to support this
behavior, although I have not seen this in any cts test case.
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
That seems ok to allow.
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.
I don't have a Nexus 7 in front of me, but we do have a restorecon
/sys/devices/tegradc.0/smartdimmer/aggressiveness in our init.grouper.rc
file and a corresponding entry in the grouper/sepolicy/file_contexts
file. Maybe we also need the equivalent for
/sys/class/graphics/fb0/device/smartdimmer/aggressiveness.
--
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.
