An issue that has been haunting loyal developers, who are sometimes scared off by the fact that they can lose revenue from a ROOTed device. ROOTed devices are also known for the security concerns when used in public networks, such as a cellular network, or public WiFi.
I am very surprised that nobody has thought of this idea, which I am about to propose to the Android community for possible consideration into the kernel source tree. Yes, this will be kernel related. As most Linux kernel developers know, they can release a kernel module which is non-GPL'd, it taints the kernel, but ultimately the developer controls the code. Nvidia and VMWare are known for tainting kernels all around the globe. Not saying, this idea needs to be developed as non-GPL, but it wouldn't hurt, if we are protecting DRM, and developers who wish to keep their income flowing from the Android market. Currently, as most websites point out, copying a bought app from the market can easily be done with ROOT access on the device, this is a security concern for current app developers who put many of their resources into delivering great apps to Android users. I would also recommend having it non-GPL'd, as it would have a slight advantage over iOS, as they cannot take the code and apply it themselves. If Android is shown to be a more secure mobile development platform, and developers know that their products cannot be stolen by a ROOT or Jailbreak, it will attract them to this platform over the insecure competition. Although at this point, I see Android succeeding over iOS. The idea: Either a Linux kernel module, or a kernel modification which proxies the system call which SU uses to change the current UID. For traditional Linux workstations, it would for example, disallow the system call for any UID greater than 999. It would still allow system services to utilize SUID permissions, and the system call for changing the UID. I have seen what SELinux can do to protect Linux systems can many dangers, and I believe this type of ability can be done. Although, I am not a fluent Linux kernel hacker, and have yet to look at how SU works internally to switch the user. However, considering how a Linux system is as secure as it is, I am sure it goes through the kernel or some sort of library to do the UID switch. It sounds more like a kernel feature to me. Currently all Android does is not ship the SU binary... This is very lazy and not really the best preventive measure to stop hackers from abusing SU. It's not hard to compile a C program that uses a system call which SU uses. Now that the NDK is available, I do hope that it does not allow direct access to such system calls that allows any application to do a UID switch. This would make the system very insecure for a mobile platform. I cannot stress enough, how much this needs to be implemented into the Android kernel, or libraries. I also cannot believe how such a security issue could have been overlooked before the release of the Android platform. In reality, only dev devices should ship with the ability to SU, application developers do not need such low-level access. Applications from the market should never need to run as ROOT. I use a Linux workstation, and only trust a few select applications with ROOT permissions. Android could also utilize the Linux chroot as well, as a preventive measure. Run every single app in a chroot, if SU is obtained somehow, it cannot escape out of the applications data directory assigned. If I were to start an Android type mobile platform from scratch, I would utilize as many Linux security features as possible to prevent exploitation of the mobile system. Does Android use SELinux? I do not believe so, although I'm not sure if it is ARM compatible. At the moment, it does seem that Linux is basically just being used a simple bootloader for the Android system, and minimal security is placed upon the Linux system. If your going to use Linux, at least use the security features which have been developed for many years and proven to work in secure server environments. Why doesn't the DelvikVM run each app in a chroot? Using a terminal emulator on the device should not really reveal the entire Linux system, but a contained directory for just that app. I feel this is a huge security concern, this basically means any app and do anything to my data, as long as it has permissions in the underlaying file system. Which it would have full permission to my SDCard and my personal data stored there. This is why and how Malware is starting to appear on the Android system. Starting with version 3 of the Android system, I would suggest taking these security concerns to mind and actually using the security features Linux has to offer to make Android just as secure as any Linux workstation. I'm sure there is a way to keep backwards compatibility and add these above security additions with little issues or overhead. I look forward to any discussions upon this idea, as I would like a more secure device in my pocket. Malware is completely unacceptable in any Linux environment, if the press says Android has Malware, this negativity will hurt GNU/Linux, which is for the most part uneffected by Malware at the time of this writting. Thank you for reading and considering this idea. -- Sent from my Pocket eDGe. -- 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.
