On 11/04/2015 03:47 PM, Stephen Smalley wrote: >On 11/04/2015 04:27 PM, Mahaveer, Vishal wrote: >> On 11/04/2015 03:07 PM, Stephen Smalley wrote: >>> On 11/04/2015 03:45 PM, Mahaveer, Vishal wrote: >>>> On 11/04/2015 11:35 AM, Stephen Smalley wrote: >>>>> On 11/03/2015 11:00 AM, Mahaveer, Vishal wrote: >>>>>> Hi, >>>>>> >>>>>> Wanted to know what is the status of rpmsg_device in latest >>>>>> seandroid >>>>> policies. >>>>>> Is it up to date with latest seandroid developments? >>>>>> >>>>>> Currently only mediaserver has access to it. >>>>>> Reason for this query is because there are no Nexus devices that >>>>>> use >>>>> rpmsg device. >>>>>> >>>>>> We have platforms that still use rpmsg device and Currently we see >>>>>> selinux denials for rpmsg_device from system_server, platform_apps >>>>>> and >>>>> untrusted_apps. >>>>> >>>>> You need to investigate why you have other processes trying to >>>>> directly access rpmsg, as this is potentially a security risk (e.g. >>>>> do you really want arbitrary third party apps to be able to >>>>> directly access the driver and potentially send arbitrary data to >>>>> the remote >>> processor?). >>>> >>>> In our case rpmsg_device is accessed by libstagefrighthw. >>>> We use rpmsg_device as hardware decoder >>>> >>>> Should I define it as video_device instead? >>>> That would take care of system_server denials. >>> >>> No, better to just add that as an allow rule (but you can do that in >>> device policy without needing to modify external/sepolicy). Are you >>> sure though that system_server is actually using it directly, or >>> could this just be noise (as below)? >> >> Yes, this is what I am doing currently (adding in device specific >policy). >> Will test and see if this can go as dontaudit rule >> >>> >>>> I am yet to figure out why systemui (platform_app) is using hardware >>> decoder. >>> >>> Are you sure it is actually using it, or is some framework/library >>> just dlopen'ing libstagefright and it is just automatically trying to >>> open the device, yet nothing actually requires it for operation? >>> Does anything break if you are enforcing? If not, you can just add a >>> dontaudit rule to silence the denial. Or you could rework >>> libstagefrighthw to only open the device if it is actually going to >>> be used, not from a constructor or something.
Thanks Smalley for all the response. I will check our libstagefrighthw implementation regarding access when no operation is intended. >> >> I don't have the detailed failure log handy, But in enforcing mode, I >> saw launcher/parts of home screen (systemui) not coming up. >> >>> >>> This is only a problem if you actually need to allow an app domain to >>> access rpmsg_device, as that is neverallow'd in AOSP policy and >>> therefore prohibited by CTS. >> >> Any reason why rpmsg_device was put in neverallow rule? >> I cannot override rpmsg access for platform_app in device specific policy >because of the neverallow rule. > >Generally we try to avoid direct app access to most device nodes, as it >opens up both the driver interface as an attack surface and whatever the >underlying hardware is (in this case the remote processor with whatever OS >and stack is running on it), which in turn can often open up access to all >of physical memory or other resources. > >In the case of rpmsg, we were particularly looking at it from the point of >view of camera devices (since that is how it was used in a particular >device), and the Android model is that only the CameraService in the >mediaserver is supposed to have direct access to that (otherwise, it cannot >enforce the camera-disabled property set by a device admin, and any app can >circumvent that setting). Understood, thank you. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
