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. 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. _______________________________________________ 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.
