> SELinux implements mandatory access control, which provides more
> fine-grained control than UID/GID-based permissions.  Processes have
> security contexts associated with them, and detailed policies describe what
> those processes can and cannot do -- everything from file system access
> control to kernel system calls.

Android already has such a mechanism:

http://developer.android.com/reference/android/Manifest.permission.html

> The Android kernel binder driver just exposes /dev/binder interface that is
> readable and writable by all apps -- everything can talk to everything.

Yes, but as on the internet, the message recipient can decide whether
or not it wants to act on the request. In the case of Android, the
kernel allows a Binder message recipient to learn the UID and GID of
the caller; the recipient can then invoke the Android framework to
determine if the caller is authorized to make the call. For example:

http://developer.android.com/reference/android/content/Context.html#checkCallingPermission(java.lang.String)

So Application A runs a Service, and also declares a Permission
READ_A_DATA. Application B declares that it wants READ_A_DATA
Permission, and the user allows it. Then, when B contacts A's Service,
A checks B has READ_A_DATA Permission. If not, A can deny the request.
A can express and enforce arbitrary policies by declaring and
requiring any Permissions it wants to.

Thus, Android already has a rich declarative policy expression and
enforcement system, and it is fundamental to the Android Framework. I
don't see what SELinux can add beyond that, or how SELinux would fit
into the Android Framework as it is designed.


-- 
http://noncombatant.org/

"These days, though, you have to be pretty technical before you can
even aspire to crudeness." — William Gibson

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to android-security-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
android-security-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to