System Hardening in Android 11 • Hacker News Board

Re: System Hardening in Android 11

#131

Post by Abishek_Muthian » Wed, Jul 01, 2020, 3:32 AM UTC

sitic wrote: post #12

In addition on Android 11 API * apps can't simply access the "external" storage (enforces scoped storage) * apps can't get a list of all installed apps (package visibility, they can specify app names and intent signatures in the Manifest they want to query) These are welcome changes in my view, but unfortunately they also seem intend to fix SafetyNet and require hardware attestation that the bootloader is not unlocke…

>I've always trusted CyanogenMod/LineageOS more then than a device manufacturer, but after >10 years of using Android I think it's finally time for me to switch to an iPhone.

I'm not trying to go inside Android vs iOS rabbit hole, as it's common knowledge that android's default privacy features pale in comparison to iOS.

But in Android you can leverage the trust of an individual app publisher as well and not forced to 'trust the manufacturer'.

e.g.

Tasker is trusted, it can automate workflows unimaginable in an iOS ecosystem and when Google's API changes broke some of its features; Google listened to the community and whitelisted it.

Don't trust default messaging app? Let Signal handle messages. If there's an SMS based exploit, rest assured Signal update to patch that would arrive faster than android update.

Got 7 year old android device, which hasn't received any system updates in say (cough) 7 years? But you only use it for web browsing, you can still use latest Firefox for android(with its own engine). Which will support latest PWA API.

This can go on and on without rooting android; none of these would be possible in iOS at least not until jailbreak(which compromises security akin to rooting) and probably until Apple steals couple of tricks from the jailbreak community.

Finally, If you are talented but poor developer from a village in India/Nigeria/any other place you can develop a PWA web app on a Raspberry Pi and release it for the world to see without any additional charges and probably profit out of it; It would work fine on Android, KaiOS, perhaps upcoming suite of pure Linux smartphone OS, but if you want it to function on iOS you'll have to invest hundreds if not thousands of dollars in equipment, pay yearly $99 fee, develop new native app with probably a new programming language, Give 30% cut to Apple when you make money out of it.

Re: System Hardening in Android 11

#132

Post by 3r8riacz » Wed, Jul 01, 2020, 4:03 AM UTC

darksaints wrote: post #118

tjoff wrote: post #19

I'm mostly worried about Termux. I can't imagine a phone without a decent terminal and I feel my options are going to be severely limited.

What sorts of uses do you have on a phone where a terminal is useful?

The openssh binary to log into hardened remote servers which are not compatible with JuiceSSH or other apps alike.

Re: System Hardening in Android 11

#133

Post by ce4 » Wed, Jul 01, 2020, 4:14 AM UTC

realusername wrote: post #126

kelnos wrote: post #71

Earlier quoted context omitted.

> Banks and other financial services like to provide some form of insurance to users wrt. losing money in a security breach, and they can't do this unless the app really is being run on a pristine, locked-down platform. This seems like a weird policy, though. I can access my bank via a web browser on a desktop computer, which is certainly not even remotely a "pristine, locked-down platform".

That even makes it weirder that a no-name Chinese phone with an unknown ROM is considered more secure than a stock LineageOS just because it's not unlocked...

Or an exploitable stock ROM (either due to slow updates or eol status after 6mo-2yrs)

Re: System Hardening in Android 11

#134

Post by caf » Wed, Jul 01, 2020, 4:17 AM UTC

Cactus2018 wrote: post #109

dstaley wrote: post #97

Earlier quoted context omitted.

This is largely due to a limitation of Android itself. If your app wants to do any sort of background task that's not tied to Google Cloud Messaging, it needs to setup those background tasks. When your phone reboots, those tasks are cleared. Many apps use the "run at startup" permission to receive a notification from the system when startup has completed. It doesn't actually mean the app is running in the background.

Oh, I see. I was under the impression that these "Run at startup" apps were using the opportunity to check-in, report telemetry, and the evil ones to start GPS tracking.

At least for the last you can go into Settings->Location and either revoke location permissions entirely or at least make sure they're set to "Allowed only while in use".

Re: System Hardening in Android 11

#135

Post by realusername » Wed, Jul 01, 2020, 4:30 AM UTC

ce4 wrote: post #133

realusername wrote: post #126

Earlier quoted context omitted.

That even makes it weirder that a no-name Chinese phone with an unknown ROM is considered more secure than a stock LineageOS just because it's not unlocked...

Or an exploitable stock ROM (either due to slow updates or eol status after 6mo-2yrs)

Indeed, there's a LOT of cheap and outdated Android devices out there, even without talking about dodgy stock ROM.

Re: System Hardening in Android 11

#136

Post by pjmlp » Wed, Jul 01, 2020, 4:49 AM UTC

saagarjha wrote: post #99

pjmlp wrote: post #87

Earlier quoted context omitted.

Modern ARM chips are required for Android 11 versions. https://security.googleblog.com/2019/08/adopting-arm-memory-... https://source.android.com/devices/tech/debug/tagged-pointer...

You've mentioned this before but as far as I am aware there are no chips shipping with MTE, and the links you provided don't support this point either. Even if MTE somehow starts shipping tomorrow I cannot see Google dropping support for every device that is older or cheaper than the one flagship that'll use it.

The official statement, is from Google and ARM, not from me.

From my links above, the TL;DR; snippets are

> Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem.

> Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support.

And from https://android-developers.googleblog.com/2020/02/Android-11...

> We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps.

For the chips without MTE they plan to configure the kernel to randomly target processes for fuzzing.

https://android-developers.googleblog.com/2020/04/android-11...

https://developer.android.com/ndk/guides/gwp-asan

> GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible.

> GWP-ASan is enabled on some randomly-selected system applications and platform executables upon process start-up (or when the zygote forks)

And from ARM official communication, https://community.arm.com/developer/ip-products/processors/b...

> Only recently, Google announced that it is adopting Arm’s MTE in Android. This is exciting news, with Google showing its continued commitment to security in the Android ecosystem. It also shows the strength of our MTE offering, with the article stating that the technology makes “it very hard (if not impossible) to exploit memory bugs.” Alongside the security benefits, the disruption caused by not addressing memory safety bugs reduces user satisfaction and increases the cost of software development. With all these threats to the Android Ecosystem, you can understand why Google has made the commitment to MTE!

So those are the words from Google's Android team and ARM, whatever ARM CPU are being shipped, or alternative CPUs that Android devices might still adopt or be using.

Re: System Hardening in Android 11

#137

Post by pjmlp » Wed, Jul 01, 2020, 4:58 AM UTC

wvenable wrote: post #128

pjmlp wrote: post #85

Earlier quoted context omitted.

I am happy with Shader Editor and C# Shell, though. For anything better I use a proper laptop.

That's my point. Everything available for Android proper is a toy. I have a Tab S6 with 8GB of RAM and 256GB of storage -- it can do a lot more than play Netflix.

My point is that I am fine with it, I don't want to code on the go on my phone, beyond some toy programming while on the bus, train or waiting for check in.

Coding on Nokia Communicator (even the latest versions) or Nokia's Linux based phones/tablets was also not the best ergonomics.

Also I don't care about having a Linux CLI or something like Termux, any kind of devenv is ok for me, so to extend my list, if you want to develop Android apps on S6, then install AIDE- IDE, it will surely appreciate those 8GB.

Re: System Hardening in Android 11

#138

Post by Namidairo » Wed, Jul 01, 2020, 5:17 AM UTC

GlitchMr wrote: post #90

Noluris wrote: post #25

Earlier quoted context omitted.

Scoped storage is going to kill all the most useful apps that I use that require full access to storage (such as SyncThing). I'm going to keep using Android 10 until I die. Or just switch to Apple, since if they're going to lock everything down, I might as well go with the company that supports their phones longer than two years.

An application can require MANAGE_EXTERNAL_STORAGE permission to access all files.

I have a feeling that certain apps will end up forcing their users to accept the popup for this permission in order to continue scanning their storage for "bad" filenames. (A few mobile games rolling their own "protection" by looking for TWRP-related folders, for example)

Re: System Hardening in Android 11

#139

Post by ce4 » Wed, Jul 01, 2020, 5:20 AM UTC

yjftsjthsd-h wrote: post #129

darksaints wrote: post #118

Earlier quoted context omitted.

What sorts of uses do you have on a phone where a terminal is useful?

* youtube-dl single-handedly would justify installing termux * rsync (backups, pulling audio files, pushing pictures) * vim * git/hg (all my notes live in a repo) * random scripts (ex. When I was losing weight, I tracked calories with some shell scripts. I also have one that uses root and /system/bin/input to automate things.)

Here:

* youtube-dl

* python

* ssh for shell access

* socat + dynamic ssh port forwards

* access android APIs [1]

* general scripting, also using [1]+[2]

* backups (rsync, pigz)

* ffmpeg to transcode .mov to mp4 from a digital camera on the go

* openssl to debug stuff/inspect certs

* dig for checking dns

[1] https://wiki.termux.com/wiki/Termux:API

[2] https://wiki.termux.com/wiki/Termux:Widget

Re: System Hardening in Android 11

#140

Post by pjmlp » Wed, Jul 01, 2020, 5:26 AM UTC

josephcsible wrote: post #92

pjmlp wrote: post #35

Earlier quoted context omitted.

The option is simple although tiresome, reimplement it in Android Java or Kotlin, instead of trying to pretend Android is Linux, given that POSIX or Linux specific calls aren't even part of NDK Stable APIs documentation. Any app that access the Linux features directly just works out of luck, given that there are no compatibility guarantees.

This doesn't really fix it. Rewriting everything in Java/Kotlin won't magically grant the terminal all of the permissions that it used to have.

True, but it will allow the use of official APIs instead and do the application the Android way.

Whatever Linux calls Termux makes use of, they aren't allowed and work by chance.

Here are the official NDK APIs,

https://developer.android.com/ndk/guides/stable_apis

Anything else is considered unstable, not guaranteed to work across devices or OS updates, or even selected for SE/seccomp validation.

Android is not Linux, no matter how many think that it is the victory of Desktop Linux.