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.
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).
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
