[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: Avoiding CTS Fail related neverallow rule, appdomain write audio_deivce
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2015-02-11 13:43:29
Message-ID: 54DB5C81.4080502 () tycho ! nsa ! gov
[Download RAW message or body]

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
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]