Identifying Interface from IPC packet data

[Tez]

I know that the interface descriptor is the interface to which IPC
data goes. from transaction data, how do I infer this value?

-Earlence

[Tez]

I've tried this :

sp<BBinder> targetIntf((BBinder*)tr.cookie);

as it is used to call transact on the target, but in my test case, i.e
an application querying the system contacts provider, I do not see any
interface that is related to the contact provider particularly or
cursors in general.

-Earlence

[Tez]

note: I am doing this in libbinder. how do I infer what was the target
and source interface name?

-Earlence

[Dianne Hackborn]

On Mon, Jun 13, 2011 at 3:23 AM, Tez <earlen...@gmail.com> wrote:

I know that the interface descriptor is the interface to which IPC
data goes. from transaction data, how do I infer this value?

No, it is not.  It is just an arbitrary string that the proxy classes puts into the Parcel so that its stub can verify an incoming IPC came from its own interface.  It is there to close a subtle security hole, not for anything else.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

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.

[Tez]

I see.
Then how do I determine in concrete terms what was the interface that
a parcel is destined for?
Eg: If the contacts provider processes a query, the transaction would
be QUERY_TRANSACTION in IContentProvider. I basically need to identify
this transaction for a specific process requesting it and then
obtaining its parcel that will be sent as a reply.

-Earlence


On Jun 13, 9:29 pm, Dianne Hackborn <hack...@android.com> wrote:

> On Mon, Jun 13, 2011 at 3:23 AM, Tez <earlencefe...@gmail.com> wrote:
> > I know that the interface descriptor is the interface to which IPC
> > data goes. from transaction data, how do I infer this value?
>
> No, it is not.  It is just an arbitrary string that the proxy classes puts
> into the Parcel so that its stub can verify an incoming IPC came from its
> own interface.  It is there to close a subtle security hole, not for
> anything else.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

On Mon, Jun 13, 2011 at 12:36 PM, Tez <earlen...@gmail.com> wrote:

Then how do I determine in concrete terms what was the interface that
a parcel is destined for?

You can't.  There is no such concept.

 

Eg: If the contacts provider processes a query, the transaction would
be QUERY_TRANSACTION in IContentProvider. I basically need to identify
this transaction for a specific process requesting it and then
obtaining its parcel that will be sent as a reply.

You can't.  The data in a transaction is not typed or carry its own meaning.  What it means depends entirely on how the target IBinder will interpret it.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Tez]

> What it means depends entirely on how the target IBinder will interpret it.

how does the target IBinder interpret it? and where?

-Earlence

On Jun 13, 9:38 pm, Dianne Hackborn <hack...@android.com> wrote:

> On Mon, Jun 13, 2011 at 12:36 PM, Tez <earlencefe...@gmail.com> wrote:
> > Then how do I determine in concrete terms what was the interface that
> > a parcel is destined for?
>
> You can't.  There is no such concept.
>
> > Eg: If the contacts provider processes a query, the transaction would
> > be QUERY_TRANSACTION in IContentProvider. I basically need to identify
> > this transaction for a specific process requesting it and then
> > obtaining its parcel that will be sent as a reply.
>
> You can't.  The data in a transaction is not typed or carry its own meaning.
>  What it means depends entirely on how the target IBinder will interpret it.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

It isn't interpreted by IBinder.  IBinder is just an interface.  The interpretation comes from whatever object that implements the IBinder being called for the transaction.

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

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Tez]

thanks.

Would modifying the binder protocol to include the id of the object
that initiated the IPC and putting it in the transaction structure be
recommended? Is it possible? what are its drawbacks?

-Earlence

[Tez]

I was thinking that if the interface descriptor is a string just to
identify the stubs, why not standardize it to actually identify the
interface?

-Earlence

[Dianne Hackborn]

By design a Parcel is not a dynamically typed object and simply is not intended to allow you to interrogate it to interpret its contents.  This is how it is intended to work.  Please don't change it.

hac...@android.com

[Tez]

umm...If the interface descriptor is used by the stub to identify the
proxy, then the stub must know the proxies ID string in advance. the
only way I see that this is possible is if the interface name is used.
Eg: android.util.IMemoryHeap, and I have actually seen this value when
I log the descriptors of transactions data structures. (but not all of
them, again I wonder why only some)

-Earlence

[Dianne Hackborn]

Again this is NOT what you seem to think it is.  This is just a convention between the implementation of each interface's proxy and stub to verify that an incoming IPC came from its own implementation, to close a security hole on top of the existing uid-based security.  (In particular: it could be possible to get an interface to a remote object that is actually a different interface type, hand it an interface to another remote object, and make it perform calls on the second object as if it is a different interface than the target object actually is.  The check allows an object receiving calls to verify that in the case where the call is coming from say its own uid that there is not such spoofing going on.)

You can't count on any of this being in there or meaning what you want or anything like that.  Yes, there are common patterns that happen a lot, but those only happen by convention and are not part of the protocol.  And this also gets back to why I originally said I wouldn't recommend doing what you are doing, because you are going to end up with very fragile code that depends on very intimate implementation details.

hac...@android.com

[Tez]

Ok, granted it will be _very_ fragile if compared to the current
situation.
But this is for a research paper, and in our "android system", if we
standardize the protocol to include such information, it won't be so
fragile, right? Note that I am not proposing to modify Parcel to
include such information, instead, I intent to have
binder_transaction_data include this information? Would this be an
acceptable method of implementation?

Maybe a little background information would help. We are trying to
solve the transitive permissions problem. Eg: If process A has the
permission to access location and provides a method to read that
value. Process B has been granted this permission on A and reads the
location value. However, Process B does NOT protect its methods and
freely provides this location to anyone who asks for it. As such, a
malicious app who has been granted internet access can send location
information out.

Our idea is to have an "IPC call stack" at the callee's point so that
it can know who has initiated a particular IPC request.

-Earlence

[Dianne Hackborn]

I've already told you that as far as I am concerned I don't see it as acceptable.  If you want to proceed and hack on things this way, feel free to go ahead, I can't stop you.  It's just not something I would recommend for the reasons I've already said.

hac...@android.com

[Tez]

hmm...then this line seems to be a deadend.
Anyway, thanks for clearing things up.

-Earlence

[Dianne Hackborn]

I'm not sure what you are looking for.  It is your research project.  You know how much you care about whatever you do being realistic production code or just a hack for whatever you are doing.  All I can speak to is how the production platform works and what I would consider acceptable to be in it.

hac...@android.com

[Tez]

We would like our research to be as close to production standards as
possible, not a far-fetched hack :)
Therefore, your help is very valuable.

-Earlence

On Jun 14, 9:54 pm, Dianne Hackborn <hack...@android.com> wrote:
> I'm not sure what you are looking for.  It is your research project.  You
> know how much you care about whatever you do being realistic production code
> or just a hack for whatever you are doing.  All I can speak to is how the
> production platform works and what I would consider acceptable to be in it.
>

> ...
>
> read more »

[Tez]

just one more point.

I have seen the AIDL generator and for each transaction code it
generates,
I see a statement that explicitly generates a
parcel.writeInterfaceToken(Interface.descriptor) at the start of every
code block.
Also, the manually coded interfaces (ActivityManagerNative,
BulkCursorNative) write this value into the parcel. This confuses me,
If the AIDL tool generates this for every interface in the system and
every manually coded interface uses this, then where are the instances
that some "random strings" are being used as interface tokens?

This is the "convention" ?

-Earlence

> ...
>
> read more »

[Dianne Hackborn]

This is a convention.  The aidl compiler can generate at any point, these are not binary compatible APIs, and there are a number of hand-written interfaces that may do different things.

Okay so I don't want to argue about this.  I have told you that the approach you want to do is extremely fragile and not something I would accept as production code.  You are free to do what you want in your own builds, but I don't think there is any more I can contribute here.

hac...@android.com