Thank you, sorry about the confusion on my part. I found this exchange between you and E, helped to explain things: http://osdir.com/ml/android-platform/2010-11/msg00034.html
So looks like ActivityManagerService is the key here, I will look at the source code in detail, and also look for the table of permissions. I am basically trying to find out how the permissions used in the checkPermission() method is translated into UIDs, PIDs and GIDs to be enforced by the kernel. Thanks, -J On Mar 1, 2:30 pm, Dianne Hackborn <[email protected]> wrote: > I wouldn't try to divide this into implicit vs. explicit -- whether or not > it is implicit depends entirely on your perspective, since ultimately > *someone* is doing the check. If it is a file access the kernel is > checking. If it is an application component access, the activity manager is > checking. If it is an IPC into a process, it may be checked at the point of > receiving the IPC. > > Also this has *nothing* to do with libraries. Libraries are *not* a > security boundary. A library by definition runs in the same process as the > application. All security in Android is based on uids and processes. The > only points where a security barrier can happen are those across processes > (or from user space to kernel space). > > > > > > > > > > On Tue, Mar 1, 2011 at 11:01 AM, Jimmyz500 <[email protected]> wrote: > > Thank you Brian and Earlence for your quick responses. Your answers > > clarified things a bit for me. > > > So if my understanding is correct, can I say that permission checking > > is really implicit, involving PIDs and GIDs checking in the file > > system by the kernel, as opposed to security being enforced by > > explicitly checking permissions tied to objects. > > > An example is if an app(a process) needs to call a library (associated > > with a feature such as location), the OS will determine if the process > > can call this library based on the GIDs associated with it, and the > > checkPermissions() API call will therefore return permission_granted > > or permission_denied. > > > Thanks very much, > > -J > > > On Feb 19, 4:18 am, Earlence <[email protected]> wrote: > > > Permission checking is performed through UIDs and PIDs. > > > These values are provided to the ActivityManagerService (which has the > > > entry point for checkPermission) through the Binder kernel module. > > > As said above, each Android process has its uid and gid set given when > > > zygote launches it. These gids are connected to permissions (eg: > > > internet,bluetooth), but not all of them. > > > For such type of permissions, just a gid check suffices. For other > > > types, the PackageManagerService maintains a data structure that > > > contains the set of given permissions. The requested permission is > > > compared against this list. > > > > Cheers, > > > Earlence > > > > On Feb 18, 8:04 pm, Brian Carlstrom <[email protected]> wrote: > > > > > On Fri, Feb 18, 2011 at 8:48 AM, Jimmyz500 <[email protected]> > > wrote: > > > > > Can someone help > > > > > to explain the sequence of events when a particular app running as a > > > > > Dalvik VM needs to check whether or not it has the permissions needed > > > > > to do certain actions or to enforce permission settings? > > > > > Dalvik VM in general on its own does not enforce permissions settings. > > > > However, a special VM called the Zygote runs as root and receives > > requests > > > > from the ActivityManager to start an application. Using > > > > Zygote.forkAndSpecialize ( a native method with C implementation), the > > VM > > > > sets the uid, gids, rlimits, etc. After that, the kernel is what is > > > > restricting access, Dalvik is uninvolved. I think Control Groups (aka > > > > cgroups) are the main mechanism there, but I haven't looked into the > > details > > > > > -bri > > > -- > > You received this message because you are subscribed to the Google Groups > > "Android Security Discussions" group. > > To post to this group, send email to > > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/android-security-discuss?hl=en. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
