The basic Android security model is to separate the applications from the operating system.
The OS is a Linux kernel that is obviously compiled for the particular processor and contains device drivers for the specific hardware. This is different for each hardware platform and is where the the work in upgrading older hardware to newer Android version lies. A "generic" manufacturer may have no incentive to do this work. Android tries to be agnostic about the underlying platform but in practice some systems turn out to be easier to upgrade. The higher layers will still make some assumptions about the chip technologies that may be difficult to code around. Various hacker groups try to upgrade their older phones to newer Android versions with mixed success. This kind of non-vendor upgrade also weakens security in several ways. The OS runs a virtual machine (Davlik) that runs the applications in isolation and provides a set of libraries and calls for the apps to use. The applications are written in byte code, not machine code, which provides and important layer of protection. Apps locked into chunks of OS allocated memory. They can not access the OS core or the hardware directly themselves so must make system calls to do this stuff. The user has to grant permissions to applications to do anything that poses a risk, eg, access the file storage, connect to the internet, send texts, etc. This happens when the application is installed. If you don't say yes, the application won't install. (Borderline social engineering?) The libraries and system calls are written carefully to prevent the applications from compromising the system integrity. This is obviously a non-trivial exercise, but if done correctly it offers a fairly solid base security model that keeps the applications away from the OS and from each other. On my reading, Android is not being compromised in this this area to great extent. However, there are some exploits. They seem to mostly require a social engineering component, like getting the user to run a downloaded application file. It is possible for a malicious application to request permissions that allow access to the wifi network/internet, local storage, and telephony functions then start doing what it likes. The Android OS is not compromised but the user is. Google would attempt to detect this type of activity and can pull the application. Of course, there's a grey area of what constitutes malicious behaviour and what constitutes valid commercial activity. Your definition and Google's censure action threshold may be different. For example, social apps will want to read your address book to find your friends on their system. Do they retain, or on-sell, this information? That's a reason to be careful about whose applications you put on your phone. If the vendor has a reputation to protect they are less likely to abuse your information. Downloading an application by an unknown vendor at a non-Google two-bob app store is just plain risky. AFAIKS the Android ecosystem would benefit from a Google-driven continuously-updated protect-and-clean component, like Microsoft's Security Essentials and ongoing malware removal OS updates program. (IMHO Microsoft have gone from being a major fail to a good performer in this area.) Anti-malware systems need to have the highest level of system access to work effectively and should be part of an integrated design. Android is a bit grey in this area, they do a reasonable job of blocking malicious applications, but are doing a lot to confirm that you are infection free. - Jim On 14 November 2013 19:37, <step...@melbpc.org.au> wrote: > Also, do the tablets using Jelly Bean also sandbox applications? > > Yes, should believe so. I doubt Android versions are THAT much different. _______________________________________________ Link mailing list Link@mailman.anu.edu.au http://mailman.anu.edu.au/mailman/listinfo/link
