Thank you, Chris. You've given quite a bit of food for thought! I'll be looking into these aspects more closely.
By the way, I have assumed that (dalvik) byte code manipulation is the best available way to try to tackle this problem. I have assumed that it won't be possible to do anything at the OS level. Now, I am not an expert on Linux/Anroid OS by any stretch of imagination. Is my assumption correct that I can't have a 'layer' added to my APK that would 'filter' all the network IO -- much like a servlet filter that would intercept each request and response to/from a given resource. ATTA On Mon, Apr 23, 2012 at 7:42 PM, Chris Stratton <[email protected]> wrote: > On Monday, April 23, 2012 1:39:05 PM UTC-4, atta wrote: >> >> Thank you Chris. I understand your points. And they are all valid ones. >> >> Custom intents are indeed tricky. I didn't really think about them. But >> now that I think about that, analysing every startActivity(intent) and >> startService(intent) -- that is not exhaustive by any means but good enough >> for the purpose of what I'm trying to achieve -- and then analyze the >> getAction(), along with maybe getType(), and disallow everything except for >> well-known actions. >> >> Makes sense? >> > > Only for blocking things that were done accidentally, or where the author > didn't expect anyone to look closely. > > First, you've missed that when you see a startActivity(intent) or > whatever, you will find it hard to know with certainty the properties of > the intent object, unless you are monitoring the code as it actually runs. > Even if you see the Intent object created from hard coded data just a few > lines before, but you can't know for a fact that some sneaky piece of > native code isn't playing tricks on the running VM's data structures, or > man-in-the-middle-ing the VM's attempts to talk to the kernel Binder driver. > > There are also many ways to send an Intent that don't involve having one > of the traditional method invocations appear in the davlik opcodes - > reflection, native code, etc. The later in particular may not be a stable > interface, but it's available to anyone who takes the trouble to figure out > how to do it on particular platform version(s). > > It's probably not an accident than Android is built around the idea of > enforcing permissions at the receiving end of the IPC or syscall. At that > point it no longer matters what games have been played under and > application's userid - the enforcement is done under the uid of the > receiver or in kernel context, and it's done at the time of the attempt > when the arguments of the request are known. > > Of course oversights in the security design of the receivers will continue > to be found. > > > > -- > You received this message because you are subscribed to the Google Groups > "Android Discuss" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-discuss/-/MvO3fwn_gosJ. > > 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-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
