> Also, as on the Internet, it's up to the individual apps to protect > themselves, rather than the infrastructure providing systemic safeguards.
And they can, and do. But, the easiest way to make sure only authorized callers invoke your IPC endpoints is to declare in your Manifest that all callers must have a given Permission. For example, for a Service: http://developer.android.com/guide/topics/manifest/service-element.html#prmsn In this case, the Android framework does handle it for you. The framework implements the feature using the imperative methods I mentioned before, but the Manifest gives you a nice declarative and automatic interface to the functionality. Normally, application developers do it this way since it's easier and easier to use safely. > I have an app on my Android device (ES File Explorer) that appears to have > unfettered access to the entire filesystem. Either ES File Explorer does not really have unfettered access, your system's distributor shipped with incorrect filesystem permissions, or your phone is rooted and ES File Explorer is running with non-standard, elevated privilege. Because I didn't like the look of ES File Explorer's permissions, I installed it on a test machine (Nexus 1 running stock Gingerbread 2.3.4). I can browse the filesystem in a manner consistent with the filesystem's permissions and ownership. For example, neither ESFE nor Terminal Emulator can access /data/data (/data is rwxrwx--x, system:system; ESFW and TE run as users that are not in the system group). I suspect ESFE does not really have unfettered access to the filesystem. It probably has the normal access to the filesystem that a normal low-privilege process does. > What protection does the OS > itself have against system calls? It's the OS that *provides* system calls. It protects itself and other processes from badly-behaving processes by enforcing simple policies with simple mechanisms, tested over decades. Granted, Linux is extremely complex and hence suffers from bugs, but adding a new subsystem that implements new policies with new mechanisms — above and beyond those new in Android! — is hardly a way to decrease bugs. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to android-security-discuss@googlegroups.com. To unsubscribe from this group, send email to android-security-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
