10 ms·

CopperheadOS: A hardened open-source operating system based on Android

190 points by ymse 10y ago

ocdtrekkie 10y ago
"It will not support devices outside of the Nexus and Pixel lines." This is really sad to me. :/ As far as we've come, everything mobile is still irritatingly device-specific.
- dublinben 10y ago
  Blame the OEMs for that. The driver situation on ARM devices is quite dire.
  - entee 10y ago
    Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. Do phone manufacturers write their own drivers for all these chips as a matter of course, or do the chip providers ship something with what they put out?
    - ultramancool 10y ago
      I think in reality it's simply a matter of everyone having their own build of the kernel and needing their own set of kernel modules. Google could have solved this in some way with Android, went for something closer to the way drivers work on Windows, a single long term service kernel that everyone builds their drivers against. But instead they told everyone to just build it themselves... resulting in the current situation. They could have also solved the updating problem in the same way. No big deal though, someone will make this build on other platforms if there's interest. It's all open source and I'm sure some 14 year olds on XDA are already racing to make it build on their phone from 1982. Then I'll probably flash it. Because that's apparently who I trust to write my phone ROM.
      - avar 10y ago
        Google's certainly at some fault here, e.g. by choosing to long-term fork Linux instead of trying to upstream their patches. But my understanding is that they couldn't "just" do something like what Windows does, they don't get to boss the OEMs around in that capacity, some of the big ones effectively have their own Android forks (Samsung) or have already forked (Amazon), and if Google starts bossing them around they're just as likely to fully fork it as be brought into the fold.
        ocdtrekkie 10y ago
        I would point out that OEMs are unable to even release an Android device without Google's permission if they want any of their devices to have access to the Play Store. Google has an extensive compatibility suite that devices must pass to even qualify to request permission to release, and Google regularly changes the requirements to enforce what they feel is a good platform. They also mandate over 20 preinstalled applications, define default search settings, and the placement of app icons on the home screen. They ABSOLUTELY do get to boss OEMs around in that capacity.
        avar 10y ago
        Amazon doesn't do this, and ship their own store. What do you think would happen if Samsung forked Android and didn't ship the Play Store? Now app developers would just upload their apps to both stores and Google's power over Android as a whole would be entirely eroded. So no, they definitely don't get to boss the OEMs around. Unlike Microsoft with Windows they don't get to just say "you can't ship Windows^HAndroid anymore". They do have a bit of hold over the OEMs in the form of it being a PITA to fork, access to Google's own apps etc. So I'm not saying they have no leverage, but it's a lot less than what Microsoft has, and definitely not enough to say "my way or the highway".
        ocdtrekkie 10y ago
        This is why Google cut a deal with Samsung to bring them more in line. (Terms are secret, as usual.) Samsung seemed like it was likely to fork before, and it's probably the only manufacturer large enough to draw app developers with it. So Google did some under the table things. Possibly actually a patent lawsuit threat, given that the deal they announced included a patent sharing arrangement.
    - Natanael_L 10y ago
      It is because ARM has never really been standardized in embedded devices.
    - zanny 10y ago
      Not at all. Vendors just fork the kernel at the fixed releases Android versions ship (ex, 3.4, 3.10, 3.18, etc) and then merge in all their proprietary bullshit violating the GPL nonsense into that tree, ship (and publish) that kernel source tree, but never merge back into Linus' tree. As a result, the device is supported only by the kernel they provide, rather than by generic Linux. And their kernel never gets updates.
    - digi_owl 10y ago
      The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers. ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something. This means you can't really cook up a generic kernel package and apply it across the product range as you can on PC.
      - ocdtrekkie 10y ago
        This seems like a fatal flaw in the design of ARM.
      - gvb 10y ago
        U-Boot and linux have the Flattened Device Tree[1] (FDT) which allows the kernel to load and configure the appropriate drivers. Your statement is true, however, that someone knowledgeable of the actual hardware has to create the correct FDT. This is slowly getting better and easier. The more intractable problem, as others observed, is that ARM hardware vendors tend to throw together a custom kernel for a given ARM processor and board and then abandon it. [1] https://en.wikipedia.org/wiki/Device_tree https://en.wikipedia.org/wiki/Device_tree
  - Ixiaus 10y ago
    It is very dire and painful :-(
- ninjin 10y ago
  "Devices will be supported until Google drops support from the Android Open Source Project. Google guarantees major version updates for at least two years after launch. Security updates are guaranteed for three years after launch along with 1.5 years after the last device is sold." As someone that is still using a phone from 2012, this is problematic since I have no intention of getting a new phone that often. Is there no stable, secure, and open combination of OS and smartphone out there?
  - ocdtrekkie 10y ago
    No, there isn't. Microsoft supports Windows Phone/Mobile for three years, which is I think the longest of anyone, but obviously it's not open.
  - ausjke 10y ago
    This is also the biggest concern to put Android into non-phone/non-tablet(i.e. no consumer devices) embedded products, which can run for years.
  - carkje9 10y ago
    Cyanogenmod still supports security updates for the Galaxy S, a model released in 2010.[0] Is it still worth using a six-year-old phone? Maybe not, but if your device is lucky enough to have support it can last you a long time. [0]https://download.cyanogenmod.org/?type=nightly&device=galaxysmtd https://download.cyanogenmod.org/?type=nightly&device=galaxy...
    - e12e 10y ago
      I recently lost my Note 3, subsequently bricked my HTC "Pico" explorer - bought as a dev phone and GPS device due to the notorious GPS issues on my first Android; a Galaxy S. So now I'm back (typing this in Firefox) on my ancient Galaxy S, running a recent cyanogen build [Ed: 11 nightly, based on Android 4.4.4 kitkat. I believe I tried 12 - but it failed to install]. It kinda works. Had to force a move from dalvik to art, and force HW rendering - there are quite a few stalls. I haven't tried encrypting the device; it's already slow enough. Ironically(?) Firefox works better than Chrome. Signal seems to work OK (only for sms so far due to missing network effect; I don't message anyone with signal installed). I'm considering just getting a new battery (replaceable battery, yay!) - as it is cheaper than getting an LG g3, nexus 5 (no memory card slot, bleh) or a Sony xperia z3 (waterproof). I wouldn't really say it's usable - but a g2 or 3 might be OK. [Ed:The low RAM on the early devices appear to me to be the worst issue. I wouldn't recommend buying a device with less than a gig of ram. the Galaxy S has ~384mb.]
fweespee_ch 10y ago
This project seems interesting but largely impractical until a truly independent FOSS app store exists with a wide selection + security track record as good as Google Play or iTunes. I don't see how it gets there with such a narrow hardware selection.
- akerro 10y ago
  https://guardianproject.info/2016/03/28/copperhead-guardian-project-and-f-droid-partner-to-build-open-verifiably-secure-mobile-ecosystem/ https://guardianproject.info/2016/03/28/copperhead-guardian-... There you go!
  - superskierpat 10y ago
    This makes the project alot more interesting to me.
- sethish 10y ago
  > security track record as good as Google Play or iTunes Do they have great security track records? I know a lot of the integrations like games into their systems are terribly insecure.
  - fweespee_ch 10y ago
    No. That is why I'm using them as the minimum standard. :p
- hackuser 10y ago
  https://f-droid.org/ https://f-droid.org/: Open source, the apps they list include the following: "This version is built and signed by F-Droid, and guaranteed to correspond to the source tarball below."
nxzero 10y ago
Besides USB Armory, are there any other open source harden hardware solutions?
- hackcasual 10y ago
  The Yubikey neo can be programmed with JavaCard. There's a handful of applets on their github
  - nxzero 10y ago
    The Yubikey neo hardware is not open source though, right?
bache 10y ago
This is a hoenypot for the NSA
- zipwitch 10y ago
  Do you mean, "this is a honeypot put out by the NSA, to see who wants this"? Or do you mean, "this is an attempt by the developers to see how the NSA tries to subvert, sabotage, or otherwise compromise their project"?
- rinon 10y ago
  That's called a baseband processor. But no, in all seriousness, Copperhead (and AOSP itself) are open source. Go audit it for NSA backdoors yourself if you're worried about that.
- omginternets 10y ago
  What makes you say that?
- Jweb_Guru 10y ago
  I know a guy who works on this. It's definitely not (not that you have any reason to trust me).
mmanfrin 10y ago
"Protection from zero-days" -- how can you make a claim like this?
- neerdowell 10y ago
  If a zero-day is found in standard Android (ala Stagefright) it's possible it won't be exploitable on Copperhead because of the hardened malloc, overflow protections, bounds sanitizing etc.
- rinon 10y ago
  I'm not affiliated with Copperhead at all, but I am familiar with the sorts of techniques they are using. Exploit mitigations, such as Address Space Layout Randomization, Control-Flow Integrity, Fine-grained Randomization, etc. provide a layer of hardening to make exploitation of a source code vulnerability harder, or even not possible on the protected device. The bug (zero-day) still exists, it's just not as exploitable to do bad stuff.
  - vox_mollis 10y ago
    ASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )
    - rinon 10y ago
      Indeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.
    - neerdowell 10y ago
      Not all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.
      - droopybuns 10y ago
        I've heard rumors that the new ASLR in Android N is actually worse than the current implementation. I don't have anything online to link to, unfortunately.
tkinom 10y ago
I like to see it enable the user to logs and optionally block connections attempt base on IP/dns names with both whitelist and blacklist. And track/logs all of them per Apk.
- dublinben 10y ago
  >And track/logs all of them per Apk. Don't run programs you can't trust.
  - bunnymancer 10y ago
    No point in a smartphone if you were to follow that mindset
    - gcb0 10y ago
      good luck with THAT mindset. edit: i never touched ios (except for my employer, but it's their data) and my Android phones all have my kernel and pf tables limiting all apps network access. specially to the local network!
  - dogma1138 10y ago
    You can't trust any program. And say you do trust but verify is a much better strategy.
- naasking 10y ago
  Whitelists and blacklists are useless security theatre. Any non-blacklisted IP could proxy to a blacklisted IP, and whitelisting just means you have to jump through hoops just to get your work done, which users will always do.
  - hackuser 10y ago
    > Any non-blacklisted IP could proxy to a blacklisted IP There always are ways to defeat any security; the goal is to make it more difficult and costly for the attacker, and blacklists do that. > whitelisting just means you have to jump through hoops just to get your work done, which users will //always// do. I agree that's true for most end-users, but the HN crowd and other power users could make good use of it.
spurgu 10y ago
Couldn't find the Android version it's based on?
- strcat 10y ago
  6.0.1_r20 for the Nexus 5 and Nexus 9, and 6.0.1_r24 for the Nexus 5X. You can see the versions of the downloads page (it uses AOSP_TAG.COPPERHEADOS_TIMESTAMP) It's the same as stock. It will move to 7.0 shortly after it's released.
homero 10y ago
Google needs to step it up
MuggleFucker 10y ago
Built by drug dealers for drug dealers.
ausjke 10y ago
How does this compare to CyanogenMod? Security is definitely important but how much should I trust this OS? Both CyanogenMod and CopperheadOS should be able to run smoothly withoug google-specific apps I believe, which is nice for some.
- dogma1138 10y ago
  The problem is the vast majority of applications actually require Google services to run on Android devices. Running an Android device without GApps is pretty much pointless unless you are really using it for a very very specific purpose.
  - ywecur 10y ago
    F-droid apps disagree
  - ForHackernews 10y ago
    It would be (relatively) easy to put together another suite of utilities offering the same API as the standard GApps, in order to allow 3rd party apps that depend on that API to function. Rumor has it Samsung has just such a project in the works, in case they need to punch the eject button on their relationship with Google: http://www.digitaltrends.com/mobile/samsungs-secret-mission-cut-google-galaxy/ http://www.digitaltrends.com/mobile/samsungs-secret-mission-...
    - carkje9 10y ago
      It's in progress. https://microg.org/ https://microg.org/
  - hackuser 10y ago
    > Running an Android device without GApps is pretty much pointless unless you are really using it for a very very specific purpose. This is an exaggeration; you can find plenty of solutions that don't require Gapps, AFAIK. However, I don't know that the typical end-user would be happy solving that problem or using imperfect workarounds. For one thing, you need some sort of GApps solution to access the Play store, AFAIK. > the vast majority of applications actually require Google services to run There are plenty of GApps subsitutes for people who want them; I've done some homework on it, but haven't gotten around to trying them and all of the following is "AFAIK"; it's just based on a bunch of reading. ---- These appear to be the two leading substitutes: * TKApps: 6 editions containing varying subsets of Google Apps http://forum.xda-developers.com/android/software/tk-gapps-t3116347 http://forum.xda-developers.com/android/software/tk-gapps-t3... http://forum.xda-developers.com/android/help/qa-tk-gapps-help-discussion-thread-t3116316 http://forum.xda-developers.com/android/help/qa-tk-gapps-hel... * MicroG Project: My impression is that this is most carefully engineered option. In addition to its full suite I think it gives you the option of installing only one component, the stripped down GMSCore, which provides substitutes for several Google Play Services APIs. https://github.com/microg https://github.com/microg http://forum.xda-developers.com/showthread.php?t=1715375 http://forum.xda-developers.com/showthread.php?t=1715375 http://forum.xda-developers.com/android/apps-games/app-microg-gmscore-floss-play-services-t3217616 http://forum.xda-developers.com/android/apps-games/app-micro... ---- Also of interest: * Blankstore: For minimal Play Store access, or maybe just the API to keep other apps happy. https://github.com/mar-v-in/BlankStore https://github.com/mar-v-in/BlankStore http://forum.xda-developers.com/showpost.php?p=29115263&postcount=84 http://forum.xda-developers.com/showpost.php?p=29115263&... * Fakestore: (I don't have a link, but it's the same concept as Blankstore) * BeansTown106's Gapps: (I don't have a link, but your search engine should find it), "very complete and work quite well" per a dev of OmniROM, a leading Android fork * GApps Browser: Google Apps sandboxed, so can login there without being logged on in web browser, for confidentiality https://f-droid.org/repository/browse/?fdfilter=browser&fdcategory=Internet&fdid=com.tobykurien.google_news https://f-droid.org/repository/browse/?fdfilter=browser&fdca...
hackuser 10y ago
Copperhead seems designed to protect against malicious attackers, but does it protect confidentiality against commercial tracking (another kind of attack)? I'll add: I haven't come across another fork of Android that focuses on security so I'm rooting for these guys.
- strcat 10y ago
  Privacy enhancements are definitely within the scope of the project. Most of the current features are exploit mitigations though. If you look through https://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview you'll see that there are a few privacy features already, and there are many in-progress. They won't be listed there until they're actually completed though.
  - hackuser 10y ago
    Are you connected to the project somehow?
    - strcat 10y ago
      Yes, I'm the (lead) developer of the OS.
      - hackuser 10y ago
        Great! Thanks for your hard work, and thanks for participating in the discussion. I've been looking forward to Copperhead's first release for awhile.
- hackuser 10y ago
  Partly in answer to my own question, they don't plan to disable Android's connections to Google. https://github.com/copperhead/bugtracker/issues/184 https://github.com/copperhead/bugtracker/issues/184 https://github.com/copperhead/bugtracker/issues/194 https://github.com/copperhead/bugtracker/issues/194 EDIT: To avoid any possible confusion, Google Apps / services aren't included in Copperhead; I'm talking about other connections to Google.
corbet 10y ago
See also: https://lwn.net/Articles/675719/ https://lwn.net/Articles/675719/
dsl 10y ago
You had me interested until "..based on Android." What we need is more original codebases in the mobile ecosystem, not endless modifications on top of the same old shaky foundation.
- conradev 10y ago
  That shaky foundation also has a large ecosystem of useful software. I guess it doesn't need to be "based on Android" to run Android apps, though. I'm not too familiar with security on Android (much more familiar with iOS) – what are the weakest links?
  - dsl 10y ago
    Android 0days at this point are so numerous, I find they are relatively worthless compared to time invested elsewhere. Other people seem to have the same experience (i've seen offers of double that amount for iOS remotes): http://blogs-images.forbes.com/andygreenberg/files/2012/11/exploitpricechart.jpg http://blogs-images.forbes.com/andygreenberg/files/2012/11/e...
    - strcat 10y ago
      Android vulnerabilities aren't more numerous than iOS vulnerabilities. The key difference is that 97% of Android devices do not get security updates. There is no need for 0 day vulnerabilities for attackers, in general. Few users have Nexus devices.
nickpsecurity 10y ago
Interesting development. Good to see another project trying to improve the mobile situation for Android. Getting us off iOS or Android without loosing all the good apps probably isn't happening due to lock-in effects and patent issues. At the least, projects that try to allow safer use of Android apps will benefit a lot of people.
aorth 10y ago
It looks like CopperheadOS has managed to upstream quite a number of mitigations! Bravo to them. This makes them the sort of OpenBSD research OS of the Android world, and everyone benefits from their work. https://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview
tempVariable 10y ago
Do they have a comparison table for how it fairs compared to cyanogen ? I'm interested if this is a good os if I want my personal data completely isolated away from any other app regardless of their initial permissions.

190 points by ymse 10y ago

"It will not support devices outside of the Nexus and Pixel lines." This is really sad to me. :/ As far as we've come, everything mobile is still irritatingly device-specific.

dublinben 10y ago
Blame the OEMs for that. The driver situation on ARM devices is quite dire.
- entee 10y ago
  Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. Do phone manufacturers write their own drivers for all these chips as a matter of course, or do the chip providers ship something with what they put out?
  - ultramancool 10y ago
    I think in reality it's simply a matter of everyone having their own build of the kernel and needing their own set of kernel modules. Google could have solved this in some way with Android, went for something closer to the way drivers work on Windows, a single long term service kernel that everyone builds their drivers against. But instead they told everyone to just build it themselves... resulting in the current situation. They could have also solved the updating problem in the same way. No big deal though, someone will make this build on other platforms if there's interest. It's all open source and I'm sure some 14 year olds on XDA are already racing to make it build on their phone from 1982. Then I'll probably flash it. Because that's apparently who I trust to write my phone ROM.
    - avar 10y ago
      Google's certainly at some fault here, e.g. by choosing to long-term fork Linux instead of trying to upstream their patches. But my understanding is that they couldn't "just" do something like what Windows does, they don't get to boss the OEMs around in that capacity, some of the big ones effectively have their own Android forks (Samsung) or have already forked (Amazon), and if Google starts bossing them around they're just as likely to fully fork it as be brought into the fold.
      - ocdtrekkie 10y ago
        I would point out that OEMs are unable to even release an Android device without Google's permission if they want any of their devices to have access to the Play Store. Google has an extensive compatibility suite that devices must pass to even qualify to request permission to release, and Google regularly changes the requirements to enforce what they feel is a good platform. They also mandate over 20 preinstalled applications, define default search settings, and the placement of app icons on the home screen. They ABSOLUTELY do get to boss OEMs around in that capacity.
        avar 10y ago
        Amazon doesn't do this, and ship their own store. What do you think would happen if Samsung forked Android and didn't ship the Play Store? Now app developers would just upload their apps to both stores and Google's power over Android as a whole would be entirely eroded. So no, they definitely don't get to boss the OEMs around. Unlike Microsoft with Windows they don't get to just say "you can't ship Windows^HAndroid anymore". They do have a bit of hold over the OEMs in the form of it being a PITA to fork, access to Google's own apps etc. So I'm not saying they have no leverage, but it's a lot less than what Microsoft has, and definitely not enough to say "my way or the highway".
        ocdtrekkie 10y ago
        This is why Google cut a deal with Samsung to bring them more in line. (Terms are secret, as usual.) Samsung seemed like it was likely to fork before, and it's probably the only manufacturer large enough to draw app developers with it. So Google did some under the table things. Possibly actually a patent lawsuit threat, given that the deal they announced included a patent sharing arrangement.
  - Natanael_L 10y ago
    It is because ARM has never really been standardized in embedded devices.
  - zanny 10y ago
    Not at all. Vendors just fork the kernel at the fixed releases Android versions ship (ex, 3.4, 3.10, 3.18, etc) and then merge in all their proprietary bullshit violating the GPL nonsense into that tree, ship (and publish) that kernel source tree, but never merge back into Linus' tree. As a result, the device is supported only by the kernel they provide, rather than by generic Linux. And their kernel never gets updates.
  - digi_owl 10y ago
    The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers. ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something. This means you can't really cook up a generic kernel package and apply it across the product range as you can on PC.
    - ocdtrekkie 10y ago
      This seems like a fatal flaw in the design of ARM.
    - gvb 10y ago
      U-Boot and linux have the Flattened Device Tree[1] (FDT) which allows the kernel to load and configure the appropriate drivers. Your statement is true, however, that someone knowledgeable of the actual hardware has to create the correct FDT. This is slowly getting better and easier. The more intractable problem, as others observed, is that ARM hardware vendors tend to throw together a custom kernel for a given ARM processor and board and then abandon it. [1] https://en.wikipedia.org/wiki/Device_tree https://en.wikipedia.org/wiki/Device_tree
- Ixiaus 10y ago
  It is very dire and painful :-(
ninjin 10y ago
"Devices will be supported until Google drops support from the Android Open Source Project. Google guarantees major version updates for at least two years after launch. Security updates are guaranteed for three years after launch along with 1.5 years after the last device is sold." As someone that is still using a phone from 2012, this is problematic since I have no intention of getting a new phone that often. Is there no stable, secure, and open combination of OS and smartphone out there?
- ocdtrekkie 10y ago
  No, there isn't. Microsoft supports Windows Phone/Mobile for three years, which is I think the longest of anyone, but obviously it's not open.
- ausjke 10y ago
  This is also the biggest concern to put Android into non-phone/non-tablet(i.e. no consumer devices) embedded products, which can run for years.
- carkje9 10y ago
  Cyanogenmod still supports security updates for the Galaxy S, a model released in 2010.[0] Is it still worth using a six-year-old phone? Maybe not, but if your device is lucky enough to have support it can last you a long time. [0]https://download.cyanogenmod.org/?type=nightly&device=galaxysmtd https://download.cyanogenmod.org/?type=nightly&device=galaxy...
  - e12e 10y ago
    I recently lost my Note 3, subsequently bricked my HTC "Pico" explorer - bought as a dev phone and GPS device due to the notorious GPS issues on my first Android; a Galaxy S. So now I'm back (typing this in Firefox) on my ancient Galaxy S, running a recent cyanogen build [Ed: 11 nightly, based on Android 4.4.4 kitkat. I believe I tried 12 - but it failed to install]. It kinda works. Had to force a move from dalvik to art, and force HW rendering - there are quite a few stalls. I haven't tried encrypting the device; it's already slow enough. Ironically(?) Firefox works better than Chrome. Signal seems to work OK (only for sms so far due to missing network effect; I don't message anyone with signal installed). I'm considering just getting a new battery (replaceable battery, yay!) - as it is cheaper than getting an LG g3, nexus 5 (no memory card slot, bleh) or a Sony xperia z3 (waterproof). I wouldn't really say it's usable - but a g2 or 3 might be OK. [Ed:The low RAM on the early devices appear to me to be the worst issue. I wouldn't recommend buying a device with less than a gig of ram. the Galaxy S has ~384mb.]

fweespee_ch 10y ago

This project seems interesting but largely impractical until a truly independent FOSS app store exists with a wide selection + security track record as good as Google Play or iTunes. I don't see how it gets there with such a narrow hardware selection.

akerro 10y ago
https://guardianproject.info/2016/03/28/copperhead-guardian-project-and-f-droid-partner-to-build-open-verifiably-secure-mobile-ecosystem/ https://guardianproject.info/2016/03/28/copperhead-guardian-... There you go!
- superskierpat 10y ago
  This makes the project alot more interesting to me.
sethish 10y ago
> security track record as good as Google Play or iTunes Do they have great security track records? I know a lot of the integrations like games into their systems are terribly insecure.
- fweespee_ch 10y ago
  No. That is why I'm using them as the minimum standard. :p
hackuser 10y ago
https://f-droid.org/ https://f-droid.org/: Open source, the apps they list include the following: "This version is built and signed by F-Droid, and guaranteed to correspond to the source tarball below."

nxzero 10y ago

Besides USB Armory, are there any other open source harden hardware solutions?

hackcasual 10y ago
The Yubikey neo can be programmed with JavaCard. There's a handful of applets on their github
- nxzero 10y ago
  The Yubikey neo hardware is not open source though, right?

bache 10y ago

This is a hoenypot for the NSA

zipwitch 10y ago
Do you mean, "this is a honeypot put out by the NSA, to see who wants this"? Or do you mean, "this is an attempt by the developers to see how the NSA tries to subvert, sabotage, or otherwise compromise their project"?
rinon 10y ago
That's called a baseband processor. But no, in all seriousness, Copperhead (and AOSP itself) are open source. Go audit it for NSA backdoors yourself if you're worried about that.
omginternets 10y ago
What makes you say that?
Jweb_Guru 10y ago
I know a guy who works on this. It's definitely not (not that you have any reason to trust me).

mmanfrin 10y ago

"Protection from zero-days" -- how can you make a claim like this?

neerdowell 10y ago
If a zero-day is found in standard Android (ala Stagefright) it's possible it won't be exploitable on Copperhead because of the hardened malloc, overflow protections, bounds sanitizing etc.
rinon 10y ago
I'm not affiliated with Copperhead at all, but I am familiar with the sorts of techniques they are using. Exploit mitigations, such as Address Space Layout Randomization, Control-Flow Integrity, Fine-grained Randomization, etc. provide a layer of hardening to make exploitation of a source code vulnerability harder, or even not possible on the protected device. The bug (zero-day) still exists, it's just not as exploitable to do bad stuff.
- vox_mollis 10y ago
  ASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )
  - rinon 10y ago
    Indeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.
  - neerdowell 10y ago
    Not all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.
    - droopybuns 10y ago
      I've heard rumors that the new ASLR in Android N is actually worse than the current implementation. I don't have anything online to link to, unfortunately.

tkinom 10y ago

I like to see it enable the user to logs and optionally block connections attempt base on IP/dns names with both whitelist and blacklist. And track/logs all of them per Apk.

dublinben 10y ago
>And track/logs all of them per Apk. Don't run programs you can't trust.
- bunnymancer 10y ago
  No point in a smartphone if you were to follow that mindset
  - gcb0 10y ago
    good luck with THAT mindset. edit: i never touched ios (except for my employer, but it's their data) and my Android phones all have my kernel and pf tables limiting all apps network access. specially to the local network!
- dogma1138 10y ago
  You can't trust any program. And say you do trust but verify is a much better strategy.
naasking 10y ago
Whitelists and blacklists are useless security theatre. Any non-blacklisted IP could proxy to a blacklisted IP, and whitelisting just means you have to jump through hoops just to get your work done, which users will always do.
- hackuser 10y ago
  > Any non-blacklisted IP could proxy to a blacklisted IP There always are ways to defeat any security; the goal is to make it more difficult and costly for the attacker, and blacklists do that. > whitelisting just means you have to jump through hoops just to get your work done, which users will //always// do. I agree that's true for most end-users, but the HN crowd and other power users could make good use of it.

spurgu 10y ago

Couldn't find the Android version it's based on?

strcat 10y ago
6.0.1_r20 for the Nexus 5 and Nexus 9, and 6.0.1_r24 for the Nexus 5X. You can see the versions of the downloads page (it uses AOSP_TAG.COPPERHEADOS_TIMESTAMP) It's the same as stock. It will move to 7.0 shortly after it's released.

homero 10y ago

Google needs to step it up

MuggleFucker 10y ago

Built by drug dealers for drug dealers.

ausjke 10y ago

How does this compare to CyanogenMod? Security is definitely important but how much should I trust this OS? Both CyanogenMod and CopperheadOS should be able to run smoothly withoug google-specific apps I believe, which is nice for some.

dogma1138 10y ago
The problem is the vast majority of applications actually require Google services to run on Android devices. Running an Android device without GApps is pretty much pointless unless you are really using it for a very very specific purpose.
- ywecur 10y ago
  F-droid apps disagree
- ForHackernews 10y ago
  It would be (relatively) easy to put together another suite of utilities offering the same API as the standard GApps, in order to allow 3rd party apps that depend on that API to function. Rumor has it Samsung has just such a project in the works, in case they need to punch the eject button on their relationship with Google: http://www.digitaltrends.com/mobile/samsungs-secret-mission-cut-google-galaxy/ http://www.digitaltrends.com/mobile/samsungs-secret-mission-...
  - carkje9 10y ago
    It's in progress. https://microg.org/ https://microg.org/
- hackuser 10y ago
  > Running an Android device without GApps is pretty much pointless unless you are really using it for a very very specific purpose. This is an exaggeration; you can find plenty of solutions that don't require Gapps, AFAIK. However, I don't know that the typical end-user would be happy solving that problem or using imperfect workarounds. For one thing, you need some sort of GApps solution to access the Play store, AFAIK. > the vast majority of applications actually require Google services to run There are plenty of GApps subsitutes for people who want them; I've done some homework on it, but haven't gotten around to trying them and all of the following is "AFAIK"; it's just based on a bunch of reading. ---- These appear to be the two leading substitutes: * TKApps: 6 editions containing varying subsets of Google Apps http://forum.xda-developers.com/android/software/tk-gapps-t3116347 http://forum.xda-developers.com/android/software/tk-gapps-t3... http://forum.xda-developers.com/android/help/qa-tk-gapps-help-discussion-thread-t3116316 http://forum.xda-developers.com/android/help/qa-tk-gapps-hel... * MicroG Project: My impression is that this is most carefully engineered option. In addition to its full suite I think it gives you the option of installing only one component, the stripped down GMSCore, which provides substitutes for several Google Play Services APIs. https://github.com/microg https://github.com/microg http://forum.xda-developers.com/showthread.php?t=1715375 http://forum.xda-developers.com/showthread.php?t=1715375 http://forum.xda-developers.com/android/apps-games/app-microg-gmscore-floss-play-services-t3217616 http://forum.xda-developers.com/android/apps-games/app-micro... ---- Also of interest: * Blankstore: For minimal Play Store access, or maybe just the API to keep other apps happy. https://github.com/mar-v-in/BlankStore https://github.com/mar-v-in/BlankStore http://forum.xda-developers.com/showpost.php?p=29115263&postcount=84 http://forum.xda-developers.com/showpost.php?p=29115263&... * Fakestore: (I don't have a link, but it's the same concept as Blankstore) * BeansTown106's Gapps: (I don't have a link, but your search engine should find it), "very complete and work quite well" per a dev of OmniROM, a leading Android fork * GApps Browser: Google Apps sandboxed, so can login there without being logged on in web browser, for confidentiality https://f-droid.org/repository/browse/?fdfilter=browser&fdcategory=Internet&fdid=com.tobykurien.google_news https://f-droid.org/repository/browse/?fdfilter=browser&fdca...

hackuser 10y ago

Copperhead seems designed to protect against malicious attackers, but does it protect confidentiality against commercial tracking (another kind of attack)? I'll add: I haven't come across another fork of Android that focuses on security so I'm rooting for these guys.

strcat 10y ago
Privacy enhancements are definitely within the scope of the project. Most of the current features are exploit mitigations though. If you look through https://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview you'll see that there are a few privacy features already, and there are many in-progress. They won't be listed there until they're actually completed though.
- hackuser 10y ago
  Are you connected to the project somehow?
  - strcat 10y ago
    Yes, I'm the (lead) developer of the OS.
    - hackuser 10y ago
      Great! Thanks for your hard work, and thanks for participating in the discussion. I've been looking forward to Copperhead's first release for awhile.
hackuser 10y ago
Partly in answer to my own question, they don't plan to disable Android's connections to Google. https://github.com/copperhead/bugtracker/issues/184 https://github.com/copperhead/bugtracker/issues/184 https://github.com/copperhead/bugtracker/issues/194 https://github.com/copperhead/bugtracker/issues/194 EDIT: To avoid any possible confusion, Google Apps / services aren't included in Copperhead; I'm talking about other connections to Google.

corbet 10y ago

See also: https://lwn.net/Articles/675719/ https://lwn.net/Articles/675719/

dsl 10y ago

You had me interested until "..based on Android." What we need is more original codebases in the mobile ecosystem, not endless modifications on top of the same old shaky foundation.

conradev 10y ago
That shaky foundation also has a large ecosystem of useful software. I guess it doesn't need to be "based on Android" to run Android apps, though. I'm not too familiar with security on Android (much more familiar with iOS) – what are the weakest links?
- dsl 10y ago
  Android 0days at this point are so numerous, I find they are relatively worthless compared to time invested elsewhere. Other people seem to have the same experience (i've seen offers of double that amount for iOS remotes): http://blogs-images.forbes.com/andygreenberg/files/2012/11/exploitpricechart.jpg http://blogs-images.forbes.com/andygreenberg/files/2012/11/e...
  - strcat 10y ago
    Android vulnerabilities aren't more numerous than iOS vulnerabilities. The key difference is that 97% of Android devices do not get security updates. There is no need for 0 day vulnerabilities for attackers, in general. Few users have Nexus devices.

nickpsecurity 10y ago

Interesting development. Good to see another project trying to improve the mobile situation for Android. Getting us off iOS or Android without loosing all the good apps probably isn't happening due to lock-in effects and patent issues. At the least, projects that try to allow safer use of Android apps will benefit a lot of people.

aorth 10y ago

It looks like CopperheadOS has managed to upstream quite a number of mitigations! Bravo to them. This makes them the sort of OpenBSD research OS of the Android world, and everyone benefits from their work. https://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview

tempVariable 10y ago

Do they have a comparison table for how it fairs compared to cyanogen ? I'm interested if this is a good os if I want my personal data completely isolated away from any other app regardless of their initial permissions.