Will, Thanks for the tips. I'll dig inot init.rc. The webserver was just an example, but this is exactly the type of info I was seeking.
Do you know of any existing documentation that explains steps needed to secure Android device (i.e. at the OEM level)? 1. sign userimage with vendor private keys 2. ensure ro.secure system property set 3. ensure no root consoles left running (e.g. such as G1 RC29) 4. ensure build phase for generating dexopt files into system image 5. Other? Thanks, Dan On Fri, Aug 21, 2009 at 11:20 AM, William Enck <[email protected]> wrote: > > Dan, > > There are a number of daemons that start on boot. Check out /init.rc on a > phone. You can define new services to start as well as the user to run them > as. However, if you want the webserver to bind to accept connections on port > 80 (or any port under 1024), it will need to be started as root. Once the > port is bound, webservers (e.g., Apache) typically drop to a user id > specified in a configuration file. > > If you don't want the webserver to start on boot, it is a little tricker. > Remember that in Linux/UNIX any executable file that has the setuid bit set > will run as the owner of the file. Hence, any executable file owned by root > with the setuid bit set will execute as root, no matter which user executes > it. This is both useful and dangerous, therefore it is best to reduce the > number of root owned setuid files on the system (Android only has ping and > netcfg). If a root owned setuid file does not properly parse input > controlled by an attacker, system compromise may result. Therefore, in the > event you want Apache to be started by a user process, I recommend creating > a setuid wrapper that takes no command line arguments and starts Apache > based on configuration files that are only writable by root. However, you > should recognize that any application will be able to start the webserver > (which may or may lead to a vulnerability in your setup). (Note, you can't > use shell scripts for setuid wrappers, but you can write a simple C program > that uses exec()). Additionally, if you don't need to bind to a port below > 1024, you can make the setuid wrapper owned by whatever user you want. > > Good luck, > > -Will > > Dan Hein wrote: > >> William, >> >> I have a very similar question about native code. However, my question >> is how native parts of the core system can be extended (such as adding a new >> native service) in a secure manner. That is, outside the Dalvik VM, is >> there a way to run native code as a "user" without root permissions? >> >> The following example is a bit "out there", but it is intended to clarify >> the above question with a concrete example. So, let's just say I want to >> build a native Apache webserver into my Android handset, perhaps for a >> piconet collaboration session with other users in the room. How could I >> start the Apache server securely if it lived in /system/bin, along side >> other apps like telnetd which have uid=0 root, gid = 0 root? Could I use >> sudo? Could I use chroot? >> >> I am not a Linux security expert. I imagine there is a fairly >> straightforward way to do the above. I just want some concrete examples. I >> would very much like to see one of the Android framework engineers >> respond... >> >> >> Thanks, >> Dan >> >> >> On Mon, Aug 17, 2009 at 12:03 PM, William Enck <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> I imagine some folks on this list have seen this (or a similar story): >> >> >> http://theandroidsite.com/2009/08/16/rooting-your-android-with-one-click/ >> >> I haven't investigated it in any depth, but my speculation is that >> the exploitation of the referenced kernel privilege escalation >> vulnerability >> (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2692) >> results from the ability to execute native code. >> >> I understand the public pressure to allow native code, and that >> Android's security model provides protection at the process level; >> however, as an Android user, I would like the ability to disallow >> third party native libraries for security purposes (defense in depth). >> >> I imagine there is a library path that can be checked somewhere to >> ensure JNI only allows the /system prefix. Alternatively, the LSM >> hook for mmap could be useful. >> >> While this won't stop users from rooting their devices when kernel >> privilege escalation vulnerabilities inevitably emerge, it provides >> a nice buffer between the time the vulnerability is found to the >> time a security patch is deployed that will protect many normal users. >> >> I'm going to take a look at generating a patch when I get a chance, >> but that might not be for a little while. If anyone starts to work >> on this, please let me know. >> >> Thanks, >> -Will >> >> >>
