PackageManagerServices keeps track of which permissions have been granted to each uid, and assigns uids to .apks. (Permissions are granted to uids through requests for them from the package(s) associated with the uid.)
On Tue, Mar 1, 2011 at 5:25 PM, Jimmyz500 <[email protected]> wrote: > 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. > > -- 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.
