2017-10-17 0:09 GMT+02:00 Laura Abbott <labbott@xxxxxxxxxx>: > On 10/10/2017 02:11 AM, Mark Brown wrote: >> On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote: >>> On 10/09/2017 03:08 PM, Mark Brown wrote: >>>> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: >> >>>>> Anyway, to move this forward I think we need to see a proof of concept >>>>> of using selinux to protect access to specific heaps. >> >>>> Aren't Unix permissions enough with separate files or am I >>>> misunderstanding what you're looking to see a proof of concept for? >> >>> The goal is to be able to restrict heap access to certain services >>> and selinux groups on Android so straight unix permissions aren't >>> sufficient. >> >> Oh, there's Android users for this? The users I was aware of were >> non-Android. Though even so I'd have thought that given that SELinux is >> a superset of Unix file permissions it ought to be sufficient to be able >> to use them. I'd been thinking people were suggesting SELinux as a >> replacement for file permissions, using the single file and the greater >> capabilities of SELinux. >> > Unix file permissions are necessary but not sufficient, they > can be used separately. Mostly what I want to see before > merging this is an example that splitting the Ion heaps provides > more protection than just keeping /dev/ion. > To give you an example on my system I have cma regions and so 2 heaps. One is for video decoding/encoding usage and one is dedicated to display. The goal is to be sure to have enough memory for each devices With only one /dev/ion nothing (except heap id mask) prohibed one video apllication to use the cma region dedicated to display. With one device per heaps I could change the permissions to be sure that only display have access to the correct heap. In android init.rc file I will have to change chmod 0666 /dev/ion chown system graphics /dev/ion to something like chmod 0666 /dev/ion1 chown system graphics /dev/ion1 chmod 0666 /dev/ion2 chown system media /dev/ion2 Android SEpolicy is defined like that allow { appdomain -isolated_app } ion_device:chr_file rw_file_perms; which means that apps could have access to /dev/ion with multiple devices we can imagine to protect some heap of being used by the apps, for example like this allow { appdomain -isolated_app } ion_device0:chr_file {open ioctl}; allow { system } ion_device1:chr_file {open ioctl}; allow { media } ion_device2:chr_file {open ioctl}; Benjamin > Thanks, > Laura _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel