Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

copperhead.co

Post reply on HN
Print view View original

91–100 of 105 posts

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

#91

Post by strcat »

hackuser wrote: post #90
hackuser wrote: post #62

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.

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/194 EDIT: To avoid any possible confusion, Google Apps / services aren't included in Copperhead; I'm talking about other connections to Google.

That's not what the response to #184 means. #194 wouldn't be open if removing that connection wasn't planned.

CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services.

The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. It could just as easily use something like example.com but Google's domain is known to have effectively 100% uptime. All that switching it would accomplish is pinging a CloudFlare/OpenShift server instead of Google. And CloudFlare might break it for users behind a VPN... so in the end, what would that really accomplish?

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

#92

Post by hackuser »

nickpsecurity wrote: post #83
viraptor wrote: post #81

Earlier quoted context omitted.

That's not a practical solution. Sure - you could write super-secure (Ada-style?) code in a verified environment (?), running on verified kernel (SL4?), on secure hardware (got any ideas how to solve rowhammer?). Realistically though - nobody does that (in a product which we can buy). Producing any application in that kind of environment would be too expensive and not possible for most companies. We don't even have s…

I'm talking things as simple as Code-Pointer Integrity, common tools recoded in safer language, or app-level sandboxing with or without microkernels. People rarely use strong stuff even if it's a straight-foward download, recompile, or configuration. Hell, most wont use protected messaging when it's as easy as Signal. It's a demand-driven problem largely about convenience and access to insecure apps. Btw, solutions l…

So where does a technical end-user find a relatively secure solution for a phone/small tablet, even if they have to pay a little for it - even $500 extra?

> With exception of Blackberry that tried something decent by integrating QNX with stellar results.

Are you saying Blackberry 10 is significantly more secure than Android and iOS?

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

#93

Post by nickpsecurity »

viraptor wrote: post #87
pcwalton wrote: post #85

Earlier quoted context omitted.

Whoa there. There's an entire spectrum of options in between "ASLR" and "formally verified everything" that defend against memory safety related RCE. Such as, for instance, writing in a memory-safe, high-level language where reasonable (which is in fact not only practical, it's what Android does ). (That's not to say ASLR isn't great as a way to harden the C and C++ code at the core levels of the system, of course. D…

I was refering to "prevents it entirely by language/compiler-level action on the target". I understand there's a whole spectrum in prevention and mitigation. But "prevents it entirely" is an extreme, just as "formally verified everything" is an extreme. I'm just ticked off by people lately repeating that ASLR is a bandaid, like it's a bad thing. It's a bandaid, but it can still crash-instead-of-own your app/system wi…

It's a bandaid because it covers up instead of fixed the root problems. Getting something through Softbound+CETS will stop almost all the memory errors because it tries to fix the cause. Same with pcwalton's Rust. Then, there's solutions that say leave all the problems there while trying to counter the results of an exploit in a "maybe it will work way" that are often bypassed. World of difference.

Note that using bandaids is A Good Thing if you have something broken already. It's just best to avoid what causes the breaks where possible and look for prevention measures. Our industry loves bandaids while systematically ignoring stuff that negates a need for them. So, I call out that problem but doesnt mean someone shouldnt use ASLR if it's the best bandaid they have.

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

#94

Post by hackuser »

strcat wrote: post #91
hackuser wrote: post #90

Earlier quoted context omitted.

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/194 EDIT: To avoid any possible confusion, Google Apps / services aren't included in Copperhead; I'm talking about other connections to Google.

That's not what the response to #184 means. #194 wouldn't be open if removing that connection wasn't planned. CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services. The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. It could just as easily use something like example.com but Google's domain i…

> CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services.

I didn't meant to imply that; I'll clarify.

> The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. ... in the end, what would that really accomplish?

The GET tells Google and the user's ISP, and probably a few others, that someone at the IP address is using Android, plus whatever is in the GET headers, and that they just booted/woke their phone (which also locates the user at home or elsewhere, in some cases). It shouldn't be hard to identify people by IP. EDIT: In these days of one mass surveillance overreach after another, by government and business, it's doesn't seem rational to assume these companies aren't monitoring users and collecting all the data they can.

> The only known case where AOSP connects to Google ...

When I read this I think, 'Copperhead's priority isn't investigating whether there are other cases.' That is Copperhead's choice; I have no criticism of them.

Personally, I very much would like just one OS that prioritizes privacy (which is attacked much more than the exploits Copperhead focuses on) and gives me full end-user control over the information my device sends to others. EDIT: Again, I appreciate Copperhead's efforts and free OS; also, I realize they can't implement everything at once

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

#95

Post by hackuser »

strcat wrote: post #89
hackuser wrote: post #86

Earlier quoted context omitted.

Are you connected to the project somehow?

Yes, I'm the (lead) developer of the OS.

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.

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

#96

Post by strcat »

hackuser wrote: post #94
strcat wrote: post #91

Earlier quoted context omitted.

That's not what the response to #184 means. #194 wouldn't be open if removing that connection wasn't planned. CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services. The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. It could just as easily use something like example.com but Google's domain i…

> CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services. I didn't meant to imply that; I'll clarify. > The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. ... in the end, what would that really accomplish? The GET tells Google and the user's ISP, and probably a few others, that someone at the…

It does this check when you connect to a new network and it repeats every so often to make sure the connection still works. It's how Android notifies you if there's a network connection but no internet access.

It's not a browser making the request so there's not much information in these requests. It's just a GET request with an unused result. It only checks to see if it succeeds. Every Android device does this, so it barely leaks any information. If it was changed to a CopperheadOS-specific URL, it would actually be leaking more information to networks.

I don't think there are other connections to Google in the base system but that doesn't extend to the user-facing apps like Chromium. I know for a fact that it doesn't make any other connections in normal usage, but there are a lot of edge cases.

We could make the internet access checks optional, but what about update checks? Those are leaking strictly more information (a phone connecting to builds.copperhead.co runs CopperheadOS and that can be seen without access to the HTTPS data) and it tells us which device is being used since it has to ask for the available updates. We don't really know how many people use CopperheadOS, but it would be possible to make a solid estimate from the update checks. Most people won't change the default of 1 check per day, so the number of checks per day in total is the approximate number of users, and the server has the IPs they connected from. It doesn't log anything itself but CloudFlare could.

F-Droid also does updates checks itself, so any F-Droid repositories that are enabled end up with similar information.

I am not really sure how this could be improved. You can use Tor... but in some ways that makes the situation worse.

An option to disable the internet access checks is possible, but I don't know what it would really accomplish. I don't want to make changes without a clear threat model in mind. So I'm not inclined to touch stuff like the internet connectivity check unless there are clear benefits rather than it just feeling right to people.

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

#97

Post by hackuser »

strcat wrote: post #96
hackuser wrote: post #94

Earlier quoted context omitted.

> CopperheadOS is not going to outright prevent connections to Google. That doesn't mean the OS is going to have Google services. I didn't meant to imply that; I'll clarify. > The only known case where AOSP connects to Google is an HTTP GET to test if internet access is available. ... in the end, what would that really accomplish? The GET tells Google and the user's ISP, and probably a few others, that someone at the…

It does this check when you connect to a new network and it repeats every so often to make sure the connection still works. It's how Android notifies you if there's a network connection but no internet access. It's not a browser making the request so there's not much information in these requests. It's just a GET request with an unused result. It only checks to see if it succeeds. Every Android device does this, so i…

Thanks for addressing my concerns.

EDIT:

Those are all excellent points. Where there are tradeoffs, perhaps you could put some settings in your security slider UI.

An optional software firewall that requires outgoing connections to be whitelisted would be great for my purposes, but everyone knows how painful those can be.

Regarding connections, I've come across the following potential issues; I haven't looked into them but they give me the impression that locking down Android's network activity is too complex even for technical users, and that only a carefully secured OS will solve the problem (a big reason I've looked forward to Copperhead):

* Some connections are made during bootup so an effective firewall somehow has to load early, or at least first in the network stack.

* The address of the DNS server, Google's, is hard-coded in an in-kernel DNS resolver. Among other issues, it makes it hard to choose a different DNS server or to identify the application doing the lookup.

* Some other kernel connection activity is hard to stop even with a firewall [1][2]

> I don't want to make changes without a clear threat model in mind.

Confidentiality is part of security, and exploits of confidentiality by businesses are almost certainly the most common security exploits.

People tend to overlook them because usually they are technically legal and currently they are a sort of technological norm -- though remember that lead and asbestos were once norms. Certainly users should have the option; they should control their data.

----

[1] http://forum.xda-developers.com/showpost.php?s=12c116f17804f...

[2] http://forum.xda-developers.com/showpost.php?s=a5c6cb3da0cb6...

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

#98

Post by strcat »

pcwalton wrote: post #85
viraptor wrote: post #81

Earlier quoted context omitted.

That's not a practical solution. Sure - you could write super-secure (Ada-style?) code in a verified environment (?), running on verified kernel (SL4?), on secure hardware (got any ideas how to solve rowhammer?). Realistically though - nobody does that (in a product which we can buy). Producing any application in that kind of environment would be too expensive and not possible for most companies. We don't even have s…

Whoa there. There's an entire spectrum of options in between "ASLR" and "formally verified everything" that defend against memory safety related RCE. Such as, for instance, writing in a memory-safe, high-level language where reasonable (which is in fact not only practical, it's what Android does ). (That's not to say ASLR isn't great as a way to harden the C and C++ code at the core levels of the system, of course. D…

Yeah, Android pushes memory safety quite hard. Most code in the ecosystem is written in memory safe languages (Java and friends). That still leaves the entire kernel and lots of performance critical or legacy code. Languages like Rust could reduce the amount of memory unsafe code on the platform but there's still going to be a lot left over even it's mostly contained in a language runtime and the low-level libraries.

Despite Android's usage of Java, most vulnerabilities are memory corruption bugs. It makes sense to focus on those since it's low-hanging fruit. High-level security/privacy changes involve much more subjective changes and usually have a perceptible impact on users. Hardening the base system is invisible, and that's a good thing.

Android already does an amazing job at the access control level via very locked down SELinux policies. There's a lot of work to do there, but it involves making changes that are going to make some Android developers/users unhappy. For example, `hidepid=2` made it into Android N from CopperheadOS and there's going to be fallout from that: https://code.google.com/p/android/issues/detail?id=205565. I think Google will end up shipping it, but it's not a sure thing.

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

#99

Post by gcb0 »

bunnymancer wrote: post #35
dublinben wrote: post #33

Earlier quoted context omitted.

>And track/logs all of them per Apk. Don't run programs you can't trust.

No point in a smartphone if you were to follow that mindset

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!

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

#100

Post by nathancahill »

tkinom wrote: post #14

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.

Something like Little Snitch for mobile? I've been running Firewall IP[0] on my jailbroken iOS device for a while and it works great. It's incredible to see the amount of needless connections apps try to spawn.

[0] http://r-rill.net/FirewalliP7/FiPDepiction.html

Post reply on HN