I don't have an Android phone so excuse my nativity but does Android allow an app to request more permissions AFTER it has already been installed and requested the original perms? If so, why? Additionally, if users cannot deny individual perms then they will have to make an all-or-nothing-decision about an app.
Why not just allow them to disable specific perms on install and provide stubbed generic data to the app if it uses those perms?
On the newer versions it generally does not ask for permissions on install but rather when they are needed, you can choose to decline, some applications might then misbehave. On older version like kitkat you are forced to accept all of the requested (and often very intrusive) permissions or not install the application at all.
I think request upon needing the permission makes a lot of sense. After all when you do an action and it requests a permission you at least have a chance to understand why it's needed.
Wouldn't it make sense to have temporary permissions? In Linux and Windows you have to sudo/admin also for one single action or a set of actions. You don't give a program access rights for eternity.
Maybe I want to use some app's location service only very rarely and I fear that it has some surveillance features integrated. If I'm ok sharing my location right now, I might not be ok sharing it always. It would be good to have the ability to give it the permission once, until a system restart, or for a limited timeframe.
There have been (third party) permissions systems which do provide generic data if the permission is denied, but the modern android permission system is more just based around developers having to acknowledge that those permissions might be denied and that they should still do their best. Currently, _all_ permissions are requested in a two stage system - the app publishes which permissions it _can_ request, and any changes to that list cause updates to pause pending user acceptance, but does not actually get to use those permissions until requested in code, which flags up a specific yes/no request prompt to the user.
The systems which provided generic data worked very well a lot of the time, but also some of the time would just subtly break things in a way which was not obvious for a non-technical user.
> The systems which provided generic data worked very well a lot of the time, but also some of the time would just subtly break things in a way which was not obvious for a non-technical user.
Is this available via a non-root API? There are those blackmailing applications that refuse to do their core functionality when a certain unrelated permission is denied (the hell you need my location, music streaming app!). If Android fed them generic data, they would quickly learn to detect it - but not if data is controlled by other Apps or the user himself.
I don't believe so, integrating such a thing is a pretty big change, though I believe there are (or at least were, last I checked) systems which didn't require a full custom OS to work with.
Requesting permissions for everything your app can possibly do at install time makes apps look scary. Here's an example.
Imaging a messaging app. It needs permission to read and write to your text messages - not so bad.
Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Contact integration? Camera integration? Access storage? These are all things that a messaging app might reasonably want to do. But seeing a big list of permissions, including things like "draw over other apps" and "make and manage phone calls" is scary to an end user. Especially for an app that's only supposed to be handling SMS.
I thought Android apps were sandboxed [1]. The "needs access to my file system" is the way for data to transfer into that sandbox.
Android should add the option for temporary data access. I would prefer turning on the access temporarily to send 1 photo, then turning it off a few minutes later.
The problem is that apps want access to my entire filesystem, otherwise they break. So a solution is to make them think they have access, while in reality they only have access to the sandbox filesystem (containing just the files I want to manipulate with that app).
If you don't mind sharing, what app are you referring to?
The file system itself should be well protected (on a non-rooted phone) as to prevent any unauthorized access to important data. Any app can only do whatever on the SD card if you give it permission to do so, but on the OS file system itself there isn't much they can do (again, on a non-rooted phone).
That shows the larger problem with Android. An app shouldn’t need access to your file system to send a photo. It should bring up a system provided photo picker and once the user chooses a set of files, the OS should give it a read only access to the file.
If a photo management app needs access to your photos, you should be able to give it access to your photo library.
I don't think that's the solution because apps may easily "bribe" the user into giving the app more access than it strictly needs. The bribing goes like: "sorry, but if you don't give me full access, then you can't use me". Simple, but very effective in most cases.
A better solution (imho) is to make the app think it has access, while in reality its access is limited to a sandbox.
That’s still a problem with the OS. Why does any app need access to the file system instead of the users photo library or access to certain files in a document store where the app only has read access to files that the user explicitly chooses in a system provided file picker or can write files to a location that the user chooses?
It’s fine that it’s an option but there is still nothing on the OS stopping an app from getting more permission. Why is the other permission even an option?
Didn't chroot() become secure / usable only late in the era of smartphones, way past creation of Android? Containers are a pretty new development, after all.
Neither linux containers nor linux chroot provide meaningful security. They’re useful for other things, but the kernel itself isn’t particularly well hardened against local privilege escalation attacks.
OpenBSD is one of the best on that front, but it is a defense-in-depth mechanism, not something designed to run known-malicious code.
> I really hate it when I need to send a single file or photo, an app suddenly "needs access to my filesystem" and I have to grant that access.
There's another way: the app could instead use Android's Intent system to request a file chooser. This switches to a separate app which already has access to the filesystem (like the built-in Gallery app), which after the user has chosen the file, returns something which allows the original app access to just that file. This mechanism exists since the first version of Android.
There's another downside: optional functionality. For instance, Firefox can use the camera, but if I never access a website which needs to use the camera, there's no need to allow Firefox to access the camera. Many Android apps have optional functionality which would require extra permissions, but if you never use these optional functions, the apps work just fine without the extra permissions.
Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.
iOS has a framework to take actions directly from notifications without requesting permission.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Or that could be provided by the operating system without needing the feature....
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Fair enough.
Contact integration? Camera integration? Access storage?
Why would it need to access storage outside of its own sandbox?
> Why would it need to access storage outside of its own sandbox?
To allow you to send and receive attachments.
Name any one permission, I'm pretty sure I'll find a reasonable case for it to be used in a messenger app.
However, a pretty strong case can be made that current permissions allow for way too much. For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker, so that the app only gets temporary, read-only access to the selected file. Similarly, for saving attachments the app needs only a virtualized location with write access.
The app still shouldn’t need access to the entire file system. The app should be able to launch a file browser, the user chooses a file and the OS gives it acccess to only that file or set of files.
Really, the problem is that all of that gets ridiculously complicated for an average smartphone users, which makes it trivial for app developers to "bribe" users by having the app essentially tell "give us permissions or else it won't work".
I'm all for aggressively delisting applications that refuse to work when non-essential permissions were not given. Something like PlayStore GDPR, only for permissions.
Is it the responsibility of the app to display the file browser? I’m not an app developer but I’d expected you could essentially call “osGiveMeAFile(constraints...)”, and it would pop up a native file picker dialog without your app ever having access to the full FS?
Then again I wouldn’t be surprised if google had botched this. They did it wrong for Google Drive apps, and as a result any app that wants to do something as outlandish as, say, opening a file requires read access to all files on your entire google drive, just to display a file picker.
Sometimes I wonder if anyone at Google actually thinks about these things, like, at all. How does this happen? What are those meetings like? Surely someone noticed? Ho do they think about “trust”? It never ceases to amaze me.
I agree. IMO, what should happen is: the app request for file(s), an isolated (as in, separate sandbox) file picker is shown to select those files, and only stream handles + metadata (size, file name without path) is returned.
For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker
The native file picker on iOS works with iCloud and third party storage providers like Dropbox, OneDrive, Google Drive, and Box. Any storage provider can integrate with it including apps that store everything locally.
I picked up a cheap Android a couple of years ago to see if mobiles had become worth the hassle yet. Permissions handling was one of the big things that convinced me they hadn't.
The most memorable example was trying to take a picture and the camera app telling me it needed permission to make phone calls. I still can't think of a single valid reason why a camera would need to make phone calls, so I refused, and blam, no pictures for me.
I don't get why this isn't blocked. If you're updating executable code, you should have to do it via Google Play. If it's just resources, sure, go ahead, but code?
If the app is structured as an interpreter running scripts, it seems easy to deliver another script. On other platforms (not sure about Android) similar tricks can be played with compiled libs.
Well, enumerating all program states is a superset of the halting problem. False positives, false negatives, and sometimes taking an infinite amount of time to get an answer: choose at least one. (Technically only true if the phone had an infinite amount of memory, but gigabytes of memory are enough to craft an input that would take well beyond the heat death of the universe to get an answer.)
In other words, even if you had some algorithm could somehow look at a program state and with 100% accuracy determine if that state was the start of an interpreter main loop, there would be at least one program where you couldn't be certain that you'd run your algorithm on every program state.
I stopped myself from typing "Halting problem" because essentially, antivirus software should not exist for the same reasons. Yet antiviruses clearly work - it's the entire premise of the article that Android is more vulnerable to droppers than classic computers running antiviruses.
So the same techniques used by antiviruses, be it heuristics, signatures of known interpreters and droppers, simulated execution could be used by app stores to drastically reduce bad actors. The fundamental weakness will always be there for advanced, unique malware.
AV itself is much less effective than many people believe. That's true in general, and this case is no exception. The conclusion of TFA:
"Interestingly enough, we have also observed that most AV's also failed in detecting the dropper campaigns (sometimes for years), meaning that some awareness needs to be raised on the topic,"
Unfortunately, preventing loading executable code on Android would break many useful apps (e.g. Termux[1]). Also, arguably, it would mean that third-party browsers couldn't exist, since javascript is code, after all (iOS doesn't have this problem, as no third-party browser engines are permitted — all browsers are just skins over Safari).
OTOH, perhaps there could be a "permission-like"[2] flag on Android where an app would have to declare that it loads external executable code. Apps that did not use this flag, but were detected as updating executable code (even if not malicious), would be banned from Google Play. Diligent users could then check whether an app used this flag, if it seemed as if it shouldn't need it and be careful.
Humans review iOS apps and their permitted functionality is fairly stringently limited, Android apps are approved and scanned by automated processes which are fairly easy to fool. (Play Protect does not rank well as an antivirus scanner according to AV-TEST.)
That being said, malware does make it into the iOS store, it just requires a fair bit more effort since an actual person is going to sit there and fiddle with the app before it can be listed.
There was a straight up jailbreak app that got through the process with a single button and all it did was apply the exploit to your phone. So I guess I wouldn't put too much faith in their reviews.
A one-off error is certainly not shocking in the scale of what an app store processes and the fact that humans make mistakes. I would argue that on average, Apple's review process is far superior to weeding out malicious apps than Google's.
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
> obviously the ban is via reviewing apps in the store, not on the software level
it's also on the software level. If you are an app and want to mark parts of your memory as executable, you need a special entitlement that requires a signature from Apple. Only a very small amount of OS-bundled apps (Safari for example) and no third-party app have this entitlement.
This is a reason why for a long time web-views embedded into apps couldn't make use of JIT compiled JavaScript: Because the web view was loaded in-process with your app, there was no way to execute any of the compiled code.
Only with WKWebView this was fixed by running the webview in a secondary process that has the necessary entitlements and then rendering the view inside of your process. Getting there took Apple quite some time though.
Only static code loaded from disk is marked executable, but that's not writable in memory and it's only loaded into memory when it has a valid code signature signed by Apple.
So unless you manage to get Apple to sign your dynamically loaded payload, even if you sneak the functionality past app-review, there's no way to execute it.
Though, the report of apps which dupe users have been there for iOS too,much less, probably due to various factors like: low % marketshare, better vetting process as you said.
How is the app-uploading mechanism different for iOS, Android? Is it too do with the fact that Android has a more open system.
I imagine the malware distribution situation is much more prevalent in markets where google's existence is nil. Would love to know how, if any, app is reviewed in such markets (e.g china?)
67 comments
[ 3.5 ms ] story [ 117 ms ] threadWhy not just allow them to disable specific perms on install and provide stubbed generic data to the app if it uses those perms?
Wouldn't it make sense to have temporary permissions? In Linux and Windows you have to sudo/admin also for one single action or a set of actions. You don't give a program access rights for eternity.
Maybe I want to use some app's location service only very rarely and I fear that it has some surveillance features integrated. If I'm ok sharing my location right now, I might not be ok sharing it always. It would be good to have the ability to give it the permission once, until a system restart, or for a limited timeframe.
The systems which provided generic data worked very well a lot of the time, but also some of the time would just subtly break things in a way which was not obvious for a non-technical user.
Is this available via a non-root API? There are those blackmailing applications that refuse to do their core functionality when a certain unrelated permission is denied (the hell you need my location, music streaming app!). If Android fed them generic data, they would quickly learn to detect it - but not if data is controlled by other Apps or the user himself.
Imaging a messaging app. It needs permission to read and write to your text messages - not so bad.
Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Contact integration? Camera integration? Access storage? These are all things that a messaging app might reasonably want to do. But seeing a big list of permissions, including things like "draw over other apps" and "make and manage phone calls" is scary to an end user. Especially for an app that's only supposed to be handling SMS.
OSes should allow me to create a sandbox for an app, so I can grant them access (and the app will not "break"), while still being secure.
Android should add the option for temporary data access. I would prefer turning on the access temporarily to send 1 photo, then turning it off a few minutes later.
https://developer.android.com/training/articles/security-tip...
See: https://developer.android.com/reference/android/Manifest.per...
If you don't mind sharing, what app are you referring to?
The file system itself should be well protected (on a non-rooted phone) as to prevent any unauthorized access to important data. Any app can only do whatever on the SD card if you give it permission to do so, but on the OS file system itself there isn't much they can do (again, on a non-rooted phone).
https://developer.android.com/training/secure-file-sharing/r...
If a photo management app needs access to your photos, you should be able to give it access to your photo library.
A better solution (imho) is to make the app think it has access, while in reality its access is limited to a sandbox.
read up!
Linux can also allow limited access to select filesystem data within a chroot() - this is done with a "bind mount."
Why these two security features were not designed around all Android apps from the beginning is beyond me.
OpenBSD is one of the best on that front, but it is a defense-in-depth mechanism, not something designed to run known-malicious code.
There's another way: the app could instead use Android's Intent system to request a file chooser. This switches to a separate app which already has access to the filesystem (like the built-in Gallery app), which after the user has chosen the file, returns something which allows the original app access to just that file. This mechanism exists since the first version of Android.
At least you can turn it off later.
There's another point in favor of requiring it. The only downside I can see is that the people who most need to be scared by it would not be.
iOS has a framework to take actions directly from notifications without requesting permission.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Or that could be provided by the operating system without needing the feature....
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Fair enough.
Contact integration? Camera integration? Access storage?
Why would it need to access storage outside of its own sandbox?
To allow you to send and receive attachments.
Name any one permission, I'm pretty sure I'll find a reasonable case for it to be used in a messenger app.
However, a pretty strong case can be made that current permissions allow for way too much. For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker, so that the app only gets temporary, read-only access to the selected file. Similarly, for saving attachments the app needs only a virtualized location with write access.
Really, the problem is that all of that gets ridiculously complicated for an average smartphone users, which makes it trivial for app developers to "bribe" users by having the app essentially tell "give us permissions or else it won't work".
I'm all for aggressively delisting applications that refuse to work when non-essential permissions were not given. Something like PlayStore GDPR, only for permissions.
Then again I wouldn’t be surprised if google had botched this. They did it wrong for Google Drive apps, and as a result any app that wants to do something as outlandish as, say, opening a file requires read access to all files on your entire google drive, just to display a file picker.
Sometimes I wonder if anyone at Google actually thinks about these things, like, at all. How does this happen? What are those meetings like? Surely someone noticed? Ho do they think about “trust”? It never ceases to amaze me.
The native file picker on iOS works with iCloud and third party storage providers like Dropbox, OneDrive, Google Drive, and Box. Any storage provider can integrate with it including apps that store everything locally.
The most memorable example was trying to take a picture and the camera app telling me it needed permission to make phone calls. I still can't think of a single valid reason why a camera would need to make phone calls, so I refused, and blam, no pictures for me.
https://simplemobiletools.github.io/
In other words, even if you had some algorithm could somehow look at a program state and with 100% accuracy determine if that state was the start of an interpreter main loop, there would be at least one program where you couldn't be certain that you'd run your algorithm on every program state.
So the same techniques used by antiviruses, be it heuristics, signatures of known interpreters and droppers, simulated execution could be used by app stores to drastically reduce bad actors. The fundamental weakness will always be there for advanced, unique malware.
"Interestingly enough, we have also observed that most AV's also failed in detecting the dropper campaigns (sometimes for years), meaning that some awareness needs to be raised on the topic,"
Unfortunately, preventing loading executable code on Android would break many useful apps (e.g. Termux[1]). Also, arguably, it would mean that third-party browsers couldn't exist, since javascript is code, after all (iOS doesn't have this problem, as no third-party browser engines are permitted — all browsers are just skins over Safari).
OTOH, perhaps there could be a "permission-like"[2] flag on Android where an app would have to declare that it loads external executable code. Apps that did not use this flag, but were detected as updating executable code (even if not malicious), would be banned from Google Play. Diligent users could then check whether an app used this flag, if it seemed as if it shouldn't need it and be careful.
[0] https://developer.apple.com/app-store/review/guidelines/#sof... (§2.5.2)
[1] https://termux.com/
[2] it wouldn't be an actual OS permission, just informational
That being said, malware does make it into the iOS store, it just requires a fair bit more effort since an actual person is going to sit there and fiddle with the app before it can be listed.
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
https://developer.apple.com/app-store/review/guidelines/#sof...
(Edit: obviously the ban is via reviewing apps in the store, not on the software level.)
it's also on the software level. If you are an app and want to mark parts of your memory as executable, you need a special entitlement that requires a signature from Apple. Only a very small amount of OS-bundled apps (Safari for example) and no third-party app have this entitlement.
This is a reason why for a long time web-views embedded into apps couldn't make use of JIT compiled JavaScript: Because the web view was loaded in-process with your app, there was no way to execute any of the compiled code.
Only with WKWebView this was fixed by running the webview in a secondary process that has the necessary entitlements and then rendering the view inside of your process. Getting there took Apple quite some time though.
Only static code loaded from disk is marked executable, but that's not writable in memory and it's only loaded into memory when it has a valid code signature signed by Apple.
So unless you manage to get Apple to sign your dynamically loaded payload, even if you sneak the functionality past app-review, there's no way to execute it.
You can't mark memory as executable and you can't have the OS load code not signed by Apple