Just as a hypothetical example, let's say I want to hook up a Wiimote to an Android device.
The Wiimote cannot enter a code and hit enter, but apart from that it's a normal Bluetooth device. Pre-Android 4.2, it was perfectly fine to connect it. Bluetooth uses the code '000000' for this and a third party application can hook through.
With Android 4.2 and 4.3, the ability to connect Bluetooth devices to connect without using a code determined by the phone was removed. It was possible to root the phone and set it to a specific MAC address for the Bluetooth interface, from which the Bluetooth code was generated, so that this Bluetooth code would be '000000' and the Wiimote would connect correctly.
Now with Android 4.4 the answer is going to effectively be 'forget it'...
I'm sorry but if what seems to become the most ubiquitous operating system out there cannot connect to probably the most ubiquitous gamepad in recent memory (and quite a few others that exhibit the same problem), using a standard that both of these devices support, then that's just a tad ridiculous. Especially if it's something as simple as this that was supported in the past.
And that's just one example.
Sure, I'm also going to complain about the fact that "it's my device, I want to use it as I want". But when you actually see the reasons coming through behind this you might understand why rooting might not be such an unreasonable request - it makes things like that, things that should work, work.
Right now there's two ways to root some devices -- though the bootloader (unlock), which allows you to securely do the changeover. And root exploits, which are security holes in the operating system and can be used to persistently write insecure/root functionality on the filesystem.
The former can only be done by you (the device owner), but in theory the latter can be done by any manner of malicious applications. dm-verity only addresses the latter.
You should still be free to unlock and flash your own ROM to your hearts content. This includes flashing rooted images that have whatever bluetooth functionality.
Of course, the reason root exploits are so popular as a way of unlocking devices is because most Android devices don't have unlockable bootloaders. I mean, I guess technically Google aren't stopping people from unlocking their devices, they're just giving the device manufacturers and phone networks a more robust way of doing so, but that doesn't really make much difference to the end user...
Also, at least on ChromeOS unlocking the bootloader disables playback of DRMed content.
Requiring a wipe is by design. If an attacker steals your phone, whats to prevent them from flashing a new system partition that lets them read off all the existing data? You can backup most (all?) of your data manually, then unlock and restore the data. Otherwise unlocking would be essentially the easiest attack vector to owning a device without the user knowing.
If people are modding their phone by loading a new kernel as well as the modified file system, they won't have a problem. So for people with unlocked bootloaders, this isn't a problem; and if a handset doesn't allow the bootloader to be unlocked, refuse to buy it! There are plenty of perfectly good (and in my opinion, superior) choices out there which allow for the bootloader to be unlocked. All of the Nexus devices, for example....
There is another advantage of using a locked down file system --- you may not be able to use a rootkit to break root and then modify the file system, but some unfriendly adversary, such as the FBI or the NSA, won't be able to do it to your phone without your knowledge, either. I would think that's worth the inconvenience of making sure you buy a phone with an unlockable bootloader. (Since unlocking the phone requires a wipe of the disk, you don't have to worry about the FBI/NSA doing this to access your data on the phone without your knowledge.)
There is another advantage of using a locked down file system --- you may not be able to use a rootkit to break root and then modify the file system, but some unfriendly adversary, such as the FBI or the NSA, won't be able to do it to your phone without your knowledge, either.
There's always the baseband. The baseband lives on its own cpu and often shares RAM with the "main" cpu. It runs closed-source, proprietary firmware that has unknown security bugs, exploits, and backdoors. It's reasonable to assume that anyone within reach of your cellphone tower has root to your device, and the NSA and LE almost certainly do. The mobsters John Ardito and Peter Peluso were caught when the FBI turned on their cellphones using the baseband and used them as microphones to pick up nearby conversations.
Assuming they're not already tappping the data centers where your private info is stored and that they haven't already had their rootkit baked into the system upfront.
Forensic tools used by law enforcement and intelligence organisations don't modify the system partition; in fact, modifying anything on the phone is highly undesirable, from a forensics point of view.
Re needing to wipe the disk:
1) Modern Android has 'adb backup' so if your phone is not locked, someone who got ahold of your phone can use it to dump your data from a non-rooted phone.
2) Law enforcement and intelligence organisations may or may not have tools to dump your data directly off a (desoldered) flash memory chip. You need to enable disk encryption (* ) to protect against this.
(* ) I'm assuming a disk encryption that's not rigged, i.e. has no key escrow available to law enforcement.
If your phone is not locked, and it's physically compromised, then you're hosed already. If this is something you care about, you probably should lock your phone, and keep it physically secure.
If your phone is locked, and there aren't any available root exploits for the system (why is why I'd agree with tytso about getting an unlockable phone -- less incentive for the community to collaborate on what are essentially weaponizeable root exploits) then a physical compromise that installs a persistent rootkit must wipe the device beforehand. (Which gets rid of your data, and is easily noticeable)
The nexus devices do not support verzion's lte network, so in the end you are left paying 650-900 for a developer version. That's fine for me, I'm a mobile developer but not many who aren't directly making money off of the device would be willing to make the same choice.
Right but the Nexus 5 does not support Verizon's 4g network. Verizon coverage is much better in the Northeast USA (where I live), so much that even if I wanted to switch to T-Mobile (or god forbid AT&T) I doubt I could.
It actually does support at least one of the bands that Verizon uses for LTE. There's a small chance that, like the Nexus 7 LTE, if you insert an already activated SIM card it might just work for LTE.
I've been using a subsidized Galaxy Nexus with LTE on Verizon's network for two years, so I'm not sure where you came up with that claim but it's wrong.
Yes the galaxy nexus a three year old phone that's, IMO, not a very good phone. My point was that just getting a nexus device isn't a very good option for a large portion of people.
It seems every headline could be interpreted in 2 ways, and I've seen a bunch of them lately:
1. a) "Evil Google Tries to Take Control of Android"
b) "Google Tries to Standardize Android and Fix Fragmentation"
2. a) "Google Taking Aim at Device Modders in Android 4.4 KitKat"
b) "Google Trying to Make Android as Secure and Unhackable as ChromeOS"
Doesn't it make sense for Google to try and stop rooting through vulnerabilities, just like Apple tries to stop jailbreaking with every update?
From what I understand, rooting should still be possible if the bootloader is unlockable (which it is for Nexus devices, HTC's devices, and I think Sony's too). Samsung and a few others, on the other hand, don't let you unlock the bootloader. So maybe we should take it up to them, and demand unlockable bootloaders, so we can modify our devices, instead of asking Google to turn a blind eye to Android exploits.
Google positioning its OS as "open" doesn't mean they have to make it easier for script kiddies and hackers to find vulnerabilities in your phone and exploit them. The fact that it makes it harder for modders to (legitimately) root some (some!) phones is unfortunate, but I think is just going to have to be a casualty in the name of better device security.
As another poster said, we should be taking this up with the Samsungs who ship devices with non-unlockable bootloaders.
Being open in this context is like being pregnant, you either are or not. You can't be half-pregnant or half-open.
The remark about the script-kiddie able to find vulnerabilities is ridiculous for a wide variety of reasons. Script-kiddies are not able to find vulnerabilities in any kind of system. Computer hackers obsessed with security do that and (most of the times) it's not easy by any means, i.e. Saurik.
In addition, I'm not sure what Saurik, the creator of Cydia, has to do with this discussion at all.
Finally, and most importantly, you don't seem to understand the current mobile market. Most users are the end-all-be-all of end users. Many people I know think that most of the apps on the iOS App Store are developed by Apple. People install apps without thinking. Tons of personal information is stored on your phone and in these apps, such as contacts and banking information.
Google/Android is open in the sense that Android is open source, so hypothetically anyone can hack on it.
You are the person who is half-pregnant. You want the normal end user experience, where you don't have to worry about compiling the operating system yourself, but you want it to be "hackable". That is not the definition of open. That is the definition of insecure. Because most Android users are not sophisticated computer users like yourself, a hackable operating system is just a bad idea.
If you want an OS that you can do whatever you want with, and is incredibly insecure, then fork Android and have at it. Do that, instead of complaining whenever Google makes changes that you don't understand and affect your somewhat specific and not very common use case.
Being open in this context is like being pregnant, you either are or not. You can't be half-pregnant or half-open.
That's ridiculous. Openness, unlike pregnancy, is a spectrum. And intent matters.
The remark about the script-kiddie able to find vulnerabilities is ridiculous
Script kiddie, random malicious hacker person, whatever. Yes, people like Saurik and other white hats are capable of finding these sorts of vulnerabilities, but certainly other kinds of black hats are capable as well.
Not really sure what you're trying to say here... seems like you're just spouting nonsense and nitpicking.
If you're talking about the standardization "issue", maybe Google realized that what it wants is not for Android to turn into another highly fragmented ecosystem of "distros" (like in the Linux world), that have little in common with each other except the kernel, and even file extensions aren't the same. Google is positioning Android as an ecosystem that can compete against iOS and Windows - a (more or less) unified ecosystem. The more unified it is, the better it is for consumers, in general.
But I think a middle ground can be created between super open/fragmented/anyone can fork and do whatever they want with it and super-closed/nobody can do anything with it except its vendor. However, Google could probably achieve the same thing, if they treated Android, like they do with Chromium and Chrome. Keep Chrome/some version of Android for themselves - while keeping Chromium/AOSP as open as possible.
As for this rooting issue, I don't really see what it has to do with being "open". They're just trying to secure it. And as I said, they can still allow bootloaders to be unlocked by the user. It's up to companies to do so, or they can take Samsung's route and try to lock them down as much as possible, even at the region level (which I disagree with, because in this case, there's zero benefit for both consumers and hackers. The benefit is only for the company).
I don't think having a exploitable kernel counts as being 'open' by any measure. I cannot understand how people are ignoring the security side of this.
> So maybe we should take it up to them, and demand unlockable bootloaders, so we can modify our devices, instead of asking Google to turn a blind eye to Android exploits.
The problem is not "we" -- we are the ones who buy the unlocked devices already. The problem is that people who don't know any better end up buying millions of devices that they only later discover have unreasonable restrictions and become landfill shortly after the manufacturer stops issuing new updates (which is often immediately).
What we should be demanding is that Google not allow the Google apps to be installed on devices with a locked boot loader.
It doesn't protect against root exploits, but it protects against data dumping with physical access. Hence why unlocking the bootloader forces a data wipe. It does not hurt users at all if there's an unlock, which all of Google's devices have.
Company 1 has a history of monopoly abuse (including giving OEMs financial incentives to not ship computers with competing OSes pre-installed).
Company 2 has let at least two (probably more) new mobile OSes bootstrap themselves using parts of its ecosystem.
Which company do you think is going to get the benefit of the doubt when introducing security features that make device modification more difficult?
That being said, I think the biggest issue with UEFI secure boot isn't the idea, it's the implementation. People have reported things like confusing, hard-to-use key enrollment interfaces (that sometimes don't work or even don't exist at all) and other crazy, undocumented restrictions (e.g. only allowing OSes with certain names). And there's a lot of concern that these issues won't be fixed in a timely fashion, because installing an alternative OS is a corner case use for most OEMs. And then there's the issue that there's no shared authority (across most OEMs) for signing off on bootloaders other than Microsoft. Add past history into all of that...
Meanwhile, on the Android side, there's a clear, standard unlocking process, implemented on the Nexus devices of each generation (worth noting that the Nexus 5 support was added to a well-known rooting tool within minutes of the tools developer getting the device). Yes, there's still potential for problems and abuse (e.g. bootloaders locked by manufacturers, usually by carrier request), but the issues and pitfalls are relatively well-understood, including ways of avoiding them (buy from manufacturers that offer a bootloader unlock process, avoid AT&T and Verizon-specific devices and so on). And these issues need to be balanced against the security benefits. There are certainly still issues to watch out for, but past history suggests that they will be balanced appropriately.
There seems to be a lot of confusion and misinformation about what dm-verity actually does in this thread. It's the same verified boot mechanism that's used by ChromeOS[1].
This just guarantees that on a locked, signed device (i.e. you haven't unlocked it to flash custom ROMs), the filesystem there is the one that's supposed to be there. Things that would be caught by this are (as the original documentation says[2]) rootkits and other persistent exploits.
You should still be able to unlock and flash your device; this is supposed to make it harder for a malicious app to root and own your (locked & signed) device persistently without you knowing.
If I cannot unlock my device, modify its software, and then relock it and continue to use the modified software, that is serious issue: you should not run your Devi e normally with an unlocked bootloader as there is then no protection against someone picking up your device, booting it into fastboot, and flashing new software (which normally is protected against as the unlock process erases all your data). This does not actually seem to verify things at this level, though (and thereby does not seem similar to the ChromeOS mechanism).
My standard procedure when I get a new android device is to (a) unlock the bootloader, and (b) install su & SuperSU, i.e. get root.
Normally the latter involves modifying the base filesystem. If I understand it right, this will prevent the normal rooting procedure and force the need to install a different kernel just to get root. Which isn't great, as I have no desire to run a non-stock kernel; they come out later with stable builds, they may have issues finding all the right drivers for the phone, etc.
I may be mistaken, and if root can still be gotten without switching the kernel, then everything is OK. Otherwise, this is a big dent in the desireability of Android to me; root is incredibly useful for doing things outside the constrained sandbox, like mounting encrypted file systems, or syncing the clock to an NTP server (!).
Well if the manufacturer isn't violating the GPL, you should be able to easily rebuild the stock kernel without this verification. But of course, that's a big 'if'.
I'd still love to see a significant kernel contributor step up to the plate and force the issue that locked bootloaders violate even GPL2. Of course all of these issues would be more straightforward if Linux had simply moved to GPL3 while it still could have.
Tl;dr "To re-iterate, if you are able to change the kernel your device uses, this feature will not be a concern. It’s possible to either disable dm-verity in the kernel, or to set it up to use your own keys to authenticate the system hash. For users who choose to buy carrier-branded devices and accept a locked bootloader, but find a way to root the device, take heed of this warning. It’s not at all unlikely (in my technical opinion) for this to happen on future devices. If you want the ability to modify the software on your phone, I’d avoid anything with a locked bootloader, and ensure you can modify the kernel (to disable or modify the dm-verity signatures)."
There's great amount of very talented people hacking on Android devices. The best thing we can hope for is that Google makes Android so anti-consumer, anti-developer and anti-hacker, that they all move Firefox OS or some other mobile GNU/Linux variant that's not Android.
> The best thing we can hope for is that Google makes Android so anti-consumer, anti-developer and anti-hacker
Except Google is doing the exact opposite. The Nexus 5 is the best off-contract phone out there hands down AND comes with an unlockable bootloader.
Google made the N5 and other kitkat devices more secure out of the box with this change AND continues to let you go nuts with your own hardware, best of both worlds.
The proper solution for users who want to modify their devices is an unlocked bootloader, not skipping the implementation of useful security features! I'm as annoyed by unrooted devices as anyone else, but blaming the security implementation is insane, sorry. The blame falls on the manufacturers and what they permit. Google (the ones making android "anti-consumer"...) ships an unlockable bootloader on all their devices.
Of the last two, you'll get no argument from me, but I would argue this is not "anti-consumer". Consumers do not care about the things developers and hackers care about. All the exploits allow for disabling security procedures that can be activated over the air.
A consumer wants a non-hackable phone, so if it lost they can lock, track, and erase it.
Does this mean we cannot have both ownership and security? No, but Google doesn't look like they are interested in that.
That's unlikely when so many people in the tech sphere (PG included) paint Google as an 'open' benevolent company fighting the 'evil' of everyone else.
A little, but they are still regarded as 'better than the others' by those who for some reason desire that Google obtain a monopoly over search and the OS.
Sony let me unlock my Xperia Z. They also release the drivers to their hardware to the open source community. Well worth supporting this effort when you next choose a handset.
Oppo goes as far as supporting development of CyanogenMod and ParanoidAndroid ports for their devices and are releasing a device in partnership with CyanogenMod.
The Nvidia Shield is Nexus-level friendly: it's just fastboot oem unlock, no special keys or APKs or anything. It's also an incredibly nice device. (I wish Nvidia made phones...)
People really need to remind themselves that rooting Android devices is fairly stupid if you actually intend on using them for anything. You're essentially turning off any of the security on the platform.
It's also separate from the question of being able to install your own OS build, which is of far greater importance.
That would be a fine argument if the "security" of the platform did not include attempts to stop people from doing normal, useful things. Why should I not be allowed to tether my phone, when the technology is there and I am already paying outrageous amounts for my data plan? Why should I have to pay my carrier even more just to have software features enabled? Why should I not be allowed to use my phone on another network?
See, "security" in this context is really about securing the carrier from users and those who might threaten users.
How is it dumb that if an android application requests root I receive a prompt to enter a PIN followed by allowing or denying it privileges? It's the same behavior on my Arch laptop except I have to type a password.
I love the Android dev community so I'm sad to see that the job is getting harder, but I don't think that implementing a verified boot mechanism is necessarily an anti-modder move by Google. They've implemented security like this to great effect on Chrome OS, which is one of the most secure operating systems you can get out of the box. It would be great for the average person to know that their Android phone is super-secure, and it would encourage the penetration of Android into enterprise and military applications, where security is a huge concern.
The Wiimote cannot enter a code and hit enter, but apart from that it's a normal Bluetooth device. Pre-Android 4.2, it was perfectly fine to connect it. Bluetooth uses the code '000000' for this and a third party application can hook through.
With Android 4.2 and 4.3, the ability to connect Bluetooth devices to connect without using a code determined by the phone was removed. It was possible to root the phone and set it to a specific MAC address for the Bluetooth interface, from which the Bluetooth code was generated, so that this Bluetooth code would be '000000' and the Wiimote would connect correctly.
Now with Android 4.4 the answer is going to effectively be 'forget it'...
I'm sorry but if what seems to become the most ubiquitous operating system out there cannot connect to probably the most ubiquitous gamepad in recent memory (and quite a few others that exhibit the same problem), using a standard that both of these devices support, then that's just a tad ridiculous. Especially if it's something as simple as this that was supported in the past.
And that's just one example.
Sure, I'm also going to complain about the fact that "it's my device, I want to use it as I want". But when you actually see the reasons coming through behind this you might understand why rooting might not be such an unreasonable request - it makes things like that, things that should work, work.