Note that the title is misleading: Android ALWAYS had a read-only /system partition.
Now they're adding a slew of SELinux policies which also enforce read-only access to /system partition. These are still applied if you remount it rw, which means that in the future users will have to modify SELinux policy to write while the OS is running.
Recovery (which is tasked with updates) will keep its write ability. Also all apps which don't write to /system partition (which includes most root apps like Titanium, etc.) will not be affected.
For people who don't use root apps this is actually good news. Strict SELinux policies are going to help boost Android security significantly. Malware devs are having a field day on Android and root access only makes it easier for them.
Bullshit. The massive holes in Android security are caused by the inept app permissions system. Restricting hackers that jump through hoops to get access to their file system even more is not going to stop the thousands of apps that spam all your contacts, etc.
Rootkits can cause way more damage than permission abuse. Spamming your contacts is nothing compared to keylogging your bank information or snatching 2FA notifications. App permissions also need to be improved but the former is higher priority IMO. ACL has existed in computer systems forever for a good reason. It's pointless if its not properly enforced via MAC.
Every single time these new SELinux changes in AOSP come up before the release of a new Android version there's some FUD about root access dying and bla bla bla. Guess what? It never happens.
Buy an open device (for example, Nexus) that lets you flash whatever software you want through the bootloader and thus recovery. Nothing prevents you from removing this security policy, which makes complete sense: nothing in Android's userland needs write access to /system, so it may as well be blocked completely.
Open devices are rarer and have limited hardware options. Say, I didn't found any affordable multi-SIM phone that fit my tastes available at the local retail (i.e. I wasn't willing to wait for a month for a remote purchase to ship) when I needed one.
Well you should address complaints to operators like AT&T and Verizon which force bootloader locks to your phones.
Here in EU pretty much most of the new Androids are fully unlockable including phones that ship with completely locked bootloaders on Verizon and AT&T.
Demanding that Google ships an OS with security vulnerabilities because US telcos demand bootloader locking is ludicrous.
The "hard-work" that it took to create the fart app? Or the one that just provides you with a button to turn on your phone's flash LED? Adding advertisements to these things is just a money-grab (especially putting ads in apps targeted at children).
If I personally created such an app, I would have issues trying to morally justify putting ads in it.
Then personally create those apps. Problem solved, no? If, however, you are installing advertiser supported apps and then trying to justify it by declaring its simplicity, you have absolutely no moral ground to stand on. You are just another thief making justifications.
You're making general assumptions about me not supported by the post that I made:
> You are just another thief making justifications.
I posted an objection to the "hard work / starving developer" statement, and now I'm apparently a thief for even suggesting that I find advertisements in those apps to be morally objectionable.
I personally do not own an Android phone. Am I a thief for suggesting that I dislike people creating these 'simple' apps and slapping them full of ads?
You also seem to think that people are not allow to speak their mind, which is an attitude that I do have moral objections to:
> Then personally create those apps. Problem solved, no?
What about when the App is full of ads (e.g. "Your phone is full of virus! Download App to clean it here!") that are meant to trick the user into clicking them? Is that also morally defensible because someone "worked hard" on it?
With a paid version of the app or an in-app purchase, sure. Sadly, some devs only have an ad-supported version. Apps that waste my screen space and download quota with ads just aren't worth it. Either the ads go (with AdAway) or the app goes.
I'm not arguing that ads aren't annoying! It's just an incredibly entitled way of thinking. Perhaps ads are the only source of income for that particular developer. Why not just use something else / get on with it / write something yourself?
Also - downvote if an answer is offensive or inappropriate, not because you disagree with an opposing point of view!
It's not an overly entitled way of thinking when it comes to a device I own that uses a data package I pay for. I don't actually run an ad blocker in my web browser, but on mobile, where screen size, battery life, and data usage constraints are very real, I can't stand them. If I couldn't remove the ads from an app I would definitely find something else.
As for the downvote, you're right, but it wasn't me. I don't have that ability yet.
I appreciate your concerns regarding the data package/battery etc., but if you look at it from the developer's point of view rather than your own, it IS entitled to think you have the right to strip out their income stream because it doesn't suit you. But hey, different strokes for different folks :-)
Downvote comment wasn't directed at you in particular!
Is this really that common any more. Prior to the 3rd version of IAP, paid app schemes were less common, but nowadays I find most add supported apps have an unlocked version on Google Play or an IAP to remove ads.
Your best bet would be to contact the developer and try to see if they would offer such a thing. They may even be willing to make a one-off exception for you.
This has been coming for quite some time. Each new version of the 4.x line had something to improve security for the average user, usually in the form of restricting an API access or changing filesystem rules.
The rules revolving around /system are a huge security issue, as you can take any permission you wish without having to inform the user. Malware authors take advantage of this.
Unfortunately su binaries install to this location for the same reason. Devices with easy to unlock bootloaders (e.g. Nexus line) or an official program to unlock the bootloader (e.g. Morotola Bootloader Unlock program) won't have much of an issue, installing alternate recovery isn't terrible on those devices. The more troubling aspect is those vendors and carriers that offer no such thing. Those vendors/carriers view the phone as their property on loan to you and that they should retain control, for whatever reason. For 90% of users, this doesn't matter, they don't bother to do anything that requires root. But the other 10% are finding their options squeezed unless they buy from specific vendors and sources.
I guess this just means that rooting the currently installed Android isn't the end-all-be-all of gaining access to your device.
We'll probably end up with versions of alternative ROMs using a custom kernel for this (e.g. either CyanogenMod will enable /system write access, or there will be two versions -- one with stock kernel, the other with /system write access).
Don't worry, each vendor will have an opportunity to screw up SE for Android policy. Additionally, many kernel flaws will be possible to use for disabling these mechanisms to once again get privilege sufficient to write to /system if needed.
This is already being done by some vendors. My Sony Xperia Z1 Compact shipped with a UK image (where things are supposedly freer), was rootable only via a long flashing process that at one point breaks the screen, had an unlockable bootloader, and had a policy keeping /system read-only built into the 4.3 kernel. If one unlocks the bootloader, the DRM keys for Sony-specific extras are lost.
I've found root without /system access is good enough for most things. Tibu works fine. ...but isn't it my phone?
All of the "no big deal" comments are really startling to me. If you bought a desktop PC where you couldn't write anything to the hard drive outside of your one allowed directory without voiding the warranty, you'd take some serious issue with that. Is "but mobile!!!" an OK justification for taking away control over hardware that people own?
And the root user is the owner of the computer. This is saying that if you buy an Android device you are not granted the privilege of owning the device.
The mindset of mobile developers is to treat the end user as an adversary. You're not meant to control your device beyond what the gatekeepers of the walled garden want you to do. They want to operate by the television model where there are a privileged few producers delivering content to the masses. It's the antithesis to the internet model of an information economy where anyone can communicate with anyone else and not need a middle-man regulating their conversation.
Most manufactorers supply tools to root your device. It's about the same as ubuntu having a root user without a password you still have to set.
Only if you buy your device from a carrier that locks it, you will have trouble with getting root access. But you should be angry at them, not at Google. Google is making Android safer to use for the general public. This ease of use and hanhdolding is one of the reasons Android is actually popular with non tech-savy people instead of any Linux desktop distro.
Mobile phones have always been more locked down than PCs, even before smartphones existed. As have other appliances such as microwave ovens, digital cameras, etc.
You can argue that smartphones shouldn't be treated as simple appliances any more, argue about the pros and cons of each approach... but the fact remains that this particular change in Android is fairly minute and doesn't affect the vast majority of users in any negative way, even the type of user that likes to tinker. In fact, it increases security.
I have been actively "hacking" in android and I never felt the need to change stuff on my /system partition. /data is the one where you need to change stuff.
The nice thing about something that works well on low end phones, it works awesome on high end phones :)
Although its not necessarily something you get for free, since we havent optimised for higher end devices you can get to a point where you have too many active apps open and chew battery, there are probably other places it can improve, but it does perform nicely on higher end devices.
I recently bought a Firefox OS device as my first smartphone and I'm really looking forward to the future of this OS. However, I have been plagued with a number of problems that make really simple tasks incredibly complicated, and I hope you guys are paying attention to bug reports because there are some major issues that have remained unaddressed for an extremely long time.
In any case, an open OS is a necessity and I'm glad that I didn't have to choose between iOS, Android, and WP for my first smartphone. After some major bugs have been addressed, I look forward to being able to buy a high end device on which I can install Firefox OS. I sincerely hope Mozilla continues to give the project a lot of attention and doesn't relegate it to Thunderbird status.
If you wanted to send me any bugs in particular that may be overlooked then please do, my email is in my profile.
In particular the early 'preview' launches havent gone as I personally would hoped, less than raw code there is a level of communication and collaboration with partner launches that dont exist with say, firefox, people have been working to address these and in particular I think the reference device / flame is going to be a release that fixes a lot of this.
Now they're adding a slew of SELinux policies which also enforce read-only access to /system partition. These are still applied if you remount it rw, which means that in the future users will have to modify SELinux policy to write while the OS is running.
Recovery (which is tasked with updates) will keep its write ability. Also all apps which don't write to /system partition (which includes most root apps like Titanium, etc.) will not be affected.