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.

Reply via email to