Yep. What the platform typically does is have the service publish a
factory interface, with a call to request a new session:
interface IMySession {
void close();
}
interface IMyService {
IMySession makeSession();
}
In makeSession(), check the uid of the caller.
If you want to check signing cert, you can get the packages associated with
the calling uid and check the cert of one of them. (All packages
associated with the same uid must be signed with the same cert.)
2011/12/16 Harri Smått <[email protected]>
> Hi,
>
> I would go for a simple handshaking mechanism quite likely. You can let
> anyone bind to your service but disallow usage of IPC methods for
> unidentified clients. E.g.
>
> 1. Client connects to service.
> 2. After connection is established, client is required to call, say,
> identify() IPC method which returns a String, Integer, what so ever.
> 3. After receiving this challenge, client has to call identify(result)
> method which gives client a session id.
> 4. For all of the later calls client has to use this session id among with
> the call.
>
> Quite obviously all this depends totally on how much security you're
> required to have within your client-service interaction but some very
> simple handshaking protocol might work surprisingly well if it's kept
> secret.
>
> --
> H
>
> On Dec 16, 2011, at 6:26 PM, Bsweet wrote:
>
> > It is the spoof part that concerns me.
> >
> > Anyone else out there have any creative ideas?
> >
> > Right now I'm considering just checking who is on the top of the
> > activity stack, but that is hokey and not reliable.
> >
> > On Dec 16, 4:30 am, Mark Murphy <[email protected]> wrote:
> >> On Thu, Dec 15, 2011 at 9:54 PM, Kristopher Micinski
> >>
> >> <[email protected]> wrote:
> >>> When you get a bind in your service (your onBind) can you just take
> >>> the intent and get component associated with it?
> >>
> >>> From Intent:
> >>> ComponentName getComponent()
> >>> Retrieve the concrete component associated with the intent.
> >>
> >> That should be the recipient, not the sender.
> >>
> >> The only way I know to find out whoboundto you is if you require
> >> that information in an extra, and that can always be spoofed. The
> >> expectation is that you should not care *who*boundto you, merely
> >> whether they had sufficient permissions to do so.
> >>
> >> --
> >> Mark Murphy (a Commons Guy)http://commonsware.com|
> http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
> >>
> >> _Android Programming Tutorials_ Version 4.1 Available!
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" 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-developers?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" 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-developers?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 Developers" 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-developers?hl=en
