Stephen, thanks for the detailed explanation. You mentioned in the past that more detailed denial logging can be enabled by compiling the kernel with CONFIG_AUDITSYSCALL. I was able to find a patch (https://github.iu.edu/nhusted/AuditdAndroid/blob/master/patches/android-kernel-goldfish-2.6.29-audit.patch) to enable this auditing for the goldfish kernel that I was using with the emulator. However, I have not been able to find a similar patch for grouper. Do you know if such a patch exists?
Thanks for the information, -Ryan -----Original Message----- From: Stephen Smalley [mailto:s...@tycho.nsa.gov] Sent: Monday, April 01, 2013 2:42 PM To: Persaud, Ryan K. Cc: seandroid-list@tycho.nsa.gov Subject: Re: /sys/devices/system/cpu denials 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.
