That's a just plain old waste of time. Preventing root won't prevent piracy. Don't believe me? Search any torrent site for iphone apps, PS3 games, or XBOX360 games. All three platforms are *very* locked down (the 360 is probably the most locked down consumer device I can think of), yet they all have a problem with piracy.
The assertion that rooted devices are a security concern for either the cellular network or public wifi is *so* asinine I don't know how you could type that without laughing. You do know they allow PC's onto the cellular network and onto public wifi right???? BTW. Remember, it's not rooting, it's openness: http://android-developers.blogspot.com/2010/12/its-not-rooting-its-openness.html On Dec 20, 1:30 am, Kevin Veroneau <[email protected]> wrote: > 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.
