Security and You

Many of you may not give it a second glance, but among all the furor and concern about permissions requested by market apps and privacy, all Custom ROMs (CyanogenMod included) ship with one major security risk — root!

We have been struggling with how to handle this for quite a bit, and took a first step with the first public CyanogenMod 9 alpha builds, by disabling the previously-default root access over USB. You can still get adb root access by running “adb root” in terminal, should you ever need it.

We recently merged 3 patches into CyanogenMod 9, to further address this: and

What follows is an explanation of the changes, how they affect you and our reasoning behind them.

What do the patches do?
They disable root selectively and in a configurable way. Users will be able to configure their exposure to root as:

  • Disabled
  • Enabled for ADB only
  • Enabled for Apps only
  • Enabled for both

How does this change affect the usage of your device, and root apps you have installed?
On a default CyanogenMod installation, root usage will have to be explicitly enabled by the user. This means that the user is fully aware that any application that uses root may perform actions that could compromise security, stability and data integrity. Once enabled, the process mirrors that of the current process, apps that request root will be flagged by the SuperUser.apk and the user will have to grant selective access.

Why the change?
At CyanogenMod, security has always been one of our primary concerns, however, we were hesitant to make a change that might disrupt the current root ecosystem. With CyanogenMod 9 we have the opportunity to do things better, whether its the code in the OS, UI/UX, or security – we are taking this time to do things with a fresh approach.

Shipping root enabled by default to 1,000,000+ devices was a gaping hole. With these changes we believe we have reached a compromise that allows enthusiasts to keep using root if they so desire but also provide a good level of security to the majority of users.

What concerns remain?
Many of you reading this are savvy enough to note a remaining hole in this approach – recovery and unlocked bootloaders. The bootloaders are out of our hands, there is little to nothing we can do on that front.

Regarding recovery – with unlocked bootloaders, a malicious user could just flash a new recovery image (without any potential security we could apply) or just dump the data partition. This however, requires physical access to the device. As such, the security standards for this are highly reliant on you, the device owner. Data encryption is available in ICS to safeguard your data. (Warning for emmc only users – encrypted /data means recovery will be non-functional.)

The onus is on you to secure your device; take care of your possessions, and this risk is minimal. Always make sure you take devices out of your car before you go into the mall and remove them from pockets before washing laundry. Common sense is a basic security tool.

But Why?
We honestly believe there are limited uses for root on CyanogenMod, and none that warrant shipping the OS defaulted to unsecured.

  • Colton

    I would like to see CyanogenMod shipped with SELinux for Android.

  • Logan

    Android should have a permission for “root” like other permissions so the user is notified when they install the app that it can request root access

  • Tom Burall

    Could the “Enabled for Apps only” option also include a list of apps that can be selected to have root access? 

  • ciwrl

    The su app already handles this aspect, so we don’t see a real need there.

  • ciwrl

    That would all but make Google acknowledge the ‘root’ as legitimate in the market. That won’t be likely to happen.

  • Kurosakiuzu

    CyanogenMod needs to get into the business with Mobile Brands (HTC, Samsung and etc) and US Carriers (Sprint, Verizon, T-Mobile and etc)… cuz it has awesome ROMs.

  • Puklu

    Sounds good, I think that’s definitely a step in the right direction. Can’t wait to get it to daily use.

  • norupz

    Clever move

  • Harold91

    Can anyone explain it in layman’s terms for the arts majors out there, not the computer science or engineering students? So if I install Cyanogenmod, it’s not really secure when browsing, using emails, making purchases from the device? Or is it unsafe only if someone steals it? Sorry, I know I sound like a moron.

  • susuamazin

    For all arts majors: instead of pushing you into the wrestling ring, cyanogen now asks you if you want to enter the ring. If you opt out, no danger. If you opt in, risk and reward.

  • Dr-Hack

    Good and safe move…
    They didn’t take the option just gave us one more…to have root or not to
    No cm need more time to be default shipped os

  • Rahul Kesarkar

    Fabulous thought! Absolutely nothin lost. It’s a win-win for both power users n the relatively naive ones!

  • A a

    How about whitelisting root apps?

  • CJ Hayden

    I can see that as a good thing. But we all use some root apps whether it is root explorer or open garden is becides the point. They are a risk. Perhaps you could have another option, say “enabled for apps only with exceptions” where you could add apps to safe to use list similar to how superuser does but with a little heavier hand.

  • Dr Fr3ak

    in the same direction of thought it would be awesome. if you would include the ability to revoke permissions for apps just as in cm7. any plans on doing so?
    i think these root management ideas are very good.

  • Joshua Talley

    This is a great idea. Maybe I can have my bacon and eat it, too. The one thing I miss running CM is being able to rent movies from the Mar…I mean Play Store. Being able to enable or disable it within the ROM would be great. I could see enabling it to run a backup in Titanium, then disabling for daily use.

  • Androidrob

    I just wish some support would start going to the Tmobile sgs2.

  • Chinpokomon

    You mean like how SuperUser does already? I mean, we basically white list our own applications in that way. If there is a system level white list, who should we trust to maintain that list? If you need root access today, the current SuperUser method provides a good security balance. For many mainstream users, they just don’t need root to begin with. I think this s a reasonable compromise.

  • Guest

    I like the direction where this is going. I am (was perhaps now) seriously thinking about flashing my phone with the vendor OS again (from CM 7.1) because of the root issue. I’d like to have password managers or similar apps on my phone and feel unconfortable if my phone provides a method to become root, which i cannot really control.

  • Caspertone2003

    I will insist on the convenience of a password for the recovery. Yes, the best is that the device is not lost/stolen but … it happens.
    Although not perfect, it is another barrier.

  • Mdjango

    Hey, do you plan to implement these changes into CyanogenMod 7.x as well?

  • vitor rubio

    i need root do do this
    Enable wifi tethering (Either Wifi, BT or USB)
    Enter Terminal emulator
    Type “su root”
    Type “iptables -P FORWARD ACCEPT”
    Type “iptables -t nat -A POSTROUTING -o rmnet0 -j MASQUERADE”in order to use wifi tether, how can i do it?

  • Thiago Prado

    I had the same issue with my Galaxy S2.
    Them I found out that you can reenable the Superuser button trough developer options.
    To do it go to “About the phone” then click 5 or 6 times on “Version Number field”, after that , developers mode will be enabled.
    Inside of developers you will see “Root Acess”, just change it and the button will appear again.

  • George Davey

    I would like to see a protected recovery that requires a strong password to run any of the restore commands. You can select to enable a command tree password. As you toggle down the list of commands everything seems normal, but when you elect to select “flash data partition” for example”, it would prompt for a password. The password would be stored and compared as a SHA2 hash, for instance.
    Anyone working on such a thing?
    If one combined this with a protected boot loader you would have a rooted phone that only the original rooter with the original password could recover.
    Alternatively making a branch in the boot loader to ask for a password before allowing recovery mode would do the same thing in a better way.

  • messiah

    Protected recovery can possibly be secure only after the bootlader
    itself had been secured. So until there is a way to secure the
    bootloader, there is no reason to go for a “protected recovery”. The bootloader is highly device- and vendor-dependent and as such it is barely touchable by the end user, let alone aftermarket OS developer.

  • George Davey

    A protected recovery would simply serve so if a novice finds your phone they cannot utilize the custom recovery without reinstalling the custom recovery because they don’t have the password to invoke the commands. Taking that one step further is a protected boot loader. They cannot restore back to factory or boot into the recovery without the password. It would reside in the boot loader. In terms of hardware abstraction what I would like to see is a more standardized structuring for boot loaders that removes some of this hardware variability whenever possible.
    Maybe legislation to get a password option forced into every boot loader as a first branch option to prevent unauthorized recovery of phones. Of course it would not be enabled by default. It is for people to be able to turn on that can actually understand it.
    If the reset vector hits a ROM boot loader that has only two branches one with a password and one without and that is set only by the post booted machine, this might work. It is a way to brick your phone for everyone but you, including all developers of the phone. This is what I want.

  • Adam Katav

    Where can I report a potential security problem?