On 02/10/2015 11:20 PM, 신재진 wrote: > Dear SEAndroid developer > > There are neverallow rule in the AOSP ( > > [https://android.googlesource.com/platform/external/sepolicy/+/master/app.te] > neverallow appdomain { > audio_device > camera_device > dm_device > radio_device > gps_device > rpmsg_device > }:chr_file { read write }; > > [https://android.googlesource.com/platform/external/sepolicy/+/master/file_contexts] > /dev/snd(/.*)?u:object_r:audio_device:s0 > > I think the purpose of this neverallow rule is that prevent application > to read/write the such devices. > > But one of application developer wanted to access to a audio_device, so > they wrote below policy rule. > > [device/<oem>/sepolicy/file_contexts] > /dev/snd/my_device_nameu:object_r:my_audio_device:s0 > > [my_app.te] > allow my_app my_audio_device:chr_file { read write ioctl open }; > > They could evade the neverallow rule and also CTS like this way. > I think current CTS can not catch these policy but it is not good way > related to security. > > In the future, CTS will be able to catch these workaround policy rule ?
We could address this through a new CTS test to check labeling of the device nodes (and other parts of the filesystem). That has been discussed but not implemented AFAIK. However, in looking at this particular case again, I see that most of these devices are readable and writable by the audio group, and frameworks/base/data/etc/platform.xml assigns the audio group to apps with the MANAGE_VOICE_KEYPHRASES permission, and frameworks/base/core/res/AndroidManifest.xml defines this permission as signature|system, so it could be assigned to any system app. This implies that the neverallow conflicts with Android's existing model for audio access and probably needs to be adjusted. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
