IssueTracker

Hi,
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks

It is generally privacy wise to limit unnecessary data disclosures across apps.

Previously, device MACs(Wi-Fi, Bluetooth)can be fetched from the /proc file system, even though the corresponding APIs are downgraded to return a fake and static value.

Re: https://code.google.com/p/android/issues/detail?id=205565#c3

Protecting privacy between applications is important, but bear in mind that the effect of this issue is that the information is being made private from the device owner.  Any time you restrict information from the device owner, it gives malware a place to hide.  Restricting the user from being able to determine what is running on his/her device is a net negative for privacy.

If protection of running process information is truly required, a third-party application-accessible permission should be provided to allow access.  Make it scary sounding and put it in a special group, e.g., a user-readable description of "Analyze device behavior and monitor running applications."

I agree with your opinion that a third-party application-accessible permission could be made, or combining it with something like the UsageStatsManager.

However entries made for protection can be abused for infiltration.
For example the new Android permission model since marshmallow:

1, We know certain sensitive device serial code is protected by the PHONE permission group:
Device's IMEI/MEID
sim(uim) card's ICCID

2, Apps can detect whether a runtime permission is revoked by the user.
3, An app can then force user to grant PHONE permission in order to permanently track the device. If user refuses, the app deliberately shuts itself down.
4, Similar tricks also apply to other permissions(location, contacts, modify settings..etc). Modify settings is for writing some persistent tracking cookies available to other apps that may be using the same user tracking SDKs.
5, A very important mitigation for #4 can be established if Google Play effectively pull down these malicious apps, however this is not case.


Such behavior is very popular among China's app developer(especially among large firms).

Thank you for taking the time to file this bug. We appreciate your feedback in the N preview release.

The behavior you're describing is working as intended. Android provides strict sandboxes that applications must run in. These sandboxes protect application data from other applications, including application metadata such as process state.

/sys and /proc are well known for leaking side channel information about processes, information which can be used to infer state about the processes. For instance, it's been documented for years that /proc access can be used to monitor for app launching, enabling phishing attacks.

  http://www.cnet.com/news/android-could-allow-mobile-ad-or-phishing-pop-ups/
  https://www.usenix.org/system/files/conference/woot12/woot12-final7.pdf

alternatively, /proc access can be maliciously used to infer application state, as described in https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-chen.pdf (and also bug 36949180)

The availability of an API to "legitimately" access these capabilities would defeat the intended purpose of this security fix. Malicious applications could merely request the permission and gain access.

If there are specific files in /sys you believe should be available to applications, but are not, please file a new bug where the request can be evaluated. For instance, /sys/devices/system/cpu is available to all processes, so it's inaccurate to say all of /sys is restricted.

Thank you for your interest in the Android N preview release.

I'm quite frankly stunned by this.

I'm an app developer, not a security researcher.  What you've cited is certainly a real problem, but I believe you are solving it in the wrong way.

And when I say I'm stunned, I mean I'm so stunned I made a demonstration video of the type of malware attack that you are describing here, and I'm running it on an Android N device:

https://www.youtube.com/watch?v=SkvHA1jBpn8

The changes that have been made to Android N which cripple SystemPanel (and other system utilities, security, and antivirus apps) will do little to stop this kind of attack.  Again, the only real beneficiaries will be the malware authors who are better able to hide.

In the video above, the fake malware app--which took about 30 minutes to write, by someone who has never written even "fake" malware before--successfully does exactly what you're talking about on an Android N device.  You're eliminating *one* way an app can monitor the operations of others, but there are myriad more.  The demo above is triggered by network activity to the target app's network.  An identical attack is possible my monitoring that app's public directory structure on the filesystem.

The real problem here is that applications are permitted to launch themselves arbitrarily.  The fake malware demo above launches from a *service*.  This behavior should ABSOLUTELY NOT BE ALLOWED.  I had no idea this was possible until I tried it (given that arbitrarily launching an app to the foreground has never come up...perhaps because the only reasons I can think for doing so are malicious).

And regarding the permissions...I really don't understand your statement here.  Malware can request the permissions?  Why do we bother asking for permissions at all then?  The point of asking for permissions is so a user can determine whether they trust a given app to do something.  Your same argument can be made regarding allowing an app to access your contacts or camera.  The same justification can be used to say that apps simply shouldn't be allowed to access either of those features, period.

One more question...why is the root directory protected?

FWIW, this brings Android in line with iOS 9, Windows Phone, ChromeOS and similar platforms. It goes a long way towards making the Android app sandbox on par with those. Applications should be completely isolated from each other unless they explicitly expose APIs to other apps. A permission granting exceptions from hidepid=2 would be easy to implement, but it isn't a great use case for a permission. Users don't have an understanding of the kind of data that's being leaked (timing information, memory address leaks, command-line parameters which may contain personal information, etc.). It would make a bit more sense as a dangerous permission but it's not possible to grant it without restarting the application, so it wouldn't really work in the existing model.

The only way I can see an exception for apps making sense is if it was included into the umbrella of device management. I think improving the built-in system management tools is the way to go though... even prior to this change, the ability to do this from untrusted apps from VERY limited. In terms of AV/IDS apps, those never made sense as untrusted apps. Those are an example of something that really does need to be built into the base system. They could never do a great job without more privileges and they need to be protected from other apps which this change is actually moving towards.

These changes really hurt indie app developers. Apps, like Tod Liebeck's SystemPanel, have millions of active users. Now, when the user updates to N, they will no longer work. At least provide a better alternative before killing our apps. As a user, I appreciate that you are attempting to make the system more secure, but this won't stop malicious apps.

This is a business killer development, and Google should take responsibility for it. To protect the OS against malicious SW is something everybody should agree. But the way this is tried to be achieved simply shows an incompetency. You could very easily update an API of yours by opening app usage to third parties and attach it to a user permission, and then restrict the use of /proc/ and /sys/.  Somebody should explain to me why Google itself, can collect such information with a system permission without making users to go on Settings and allow it!!! Which businesses are you targeting? This is against the antitrust laws. Expect some legal challenges...

There's no permission tied to it so Google apps don't have a way to access this either. It's only for some components of the base system, including system_server which is how the Settings app obtains information (indirectly). The security implications of this include the ability to spy on things like keyboard input in other apps via timing side channels. The SELinux /proc restrictions combined with hidepid=2 prevent issues like https://www.lightbluetouchpaper.org/2016/07/29/yet-another-android-side-channel/. The implications of a permission for viewing process information wouldn't be something users would understand, unlike the existing user-facing permissions which are all tied to personal information access.

Check your facts Daniel, Google Play Services has App Usage permission as well as Google Play Store. Google Play can easily use such info for commercial purposes, for advertisement etc. This is a very clear case of antitrust laws violation. If third parties do not collect app usage, so shall not Google. Period. But it does.
Do not give any decision on behalf of the users. They know more than you do, do not underestimate people's intelligence. This is called freedom. They might give permission to access data
Security issues can be solved in many other ways.  You want to prevent spying, you can. App usage has nothing to do with keyboard input. Fix the one you need to fix.

I agree procfs access should be protected to prevent side channel attacks.  However, the idea that this protection requires the user be entirely prevented from determining what is running on his/her device is absurd.  Absolute denial of procfs access plugs a difficult-to-exploit security hole at the cost of giving malware a perfect means to hide.  This is a net negative.

Yes, you can explain this to the user.  You can give it a short name, like "monitor and analyze other applications".  It could even be implemented as a device administrator permission (as is the ability to lock the screen).  Or though I would not recommend it, it could even be set up like the android.permission.PACKAGE_USAGE_STATS permission, where the user must directly grant it from the system settings activity.

And if none of that is acceptable, just provide an Android API to obtain the data.

But alas, I think this is all paranoia over the any-app-can-launch-itself-at-any-time-to-impersonate-anything-else-problem.  That is a problem that security researchers pointed out FIVE YEARS AGO.  And it isn't fixed in Android Nougat.  And yes, preventing procfs access will prevent *one* of the *uncountably many* ways that an app might make use of that giant security hole.  

STOP FOCUSING ON THINGS THAT MINORLY HELP MALWARE AUTHORS TO EXPLOIT THE GIANT SECURITY HOLE, AND START FOCUSING ON FIXING THE GIANT SECURITY HOLE.

https://www.youtube.com/watch?v=SkvHA1jBpn8    <= another link to my video, a demo of that security hole being exploited on Android N to steal money from your bank account.  

[Comment deleted]

It was a huge security hole permitting keylogging and other information leaks, and it really doesn't matter if there are still other security holes to be fixed. These issues aren't going to be fixed by refusing to do anything until there's a giant patch set solving everything at once. There are plenty of changes that should happen like having a permission required to access the clipboard from the background. They are entirely orthogonal. It has nothing to with /proc access. Neither does access to things like app usage information.

This change came from CopperheadOS, which doesn't have Play Services. A Google security engineer agreed with the value in having it and they ported it to AOSP master and fixed some additional compatibility issues. There's no grand conspiracy behind it. It's not anti-competitive to remove clear security holes and to harden the system. It's unfortunate that there are legitimate use cases that are no longer being served as well, and that's something to improve. It makes a lot of sense for Settings to expose more information, and for it to be less hidden. Settings itself doesn't have access to /proc though, it gets the information from system_server indirectly and it's mostly not real-time information.

Solving UX design issues is going to require UX design. It's not something that security engineers working primarily on low-level code are going to be able to do alone, so you're really complaining to the wrong people about security issues at that layer.

If the malware has system/root access, it can easily hide itself whether or not apps have access to these APIs. If it doesn't have system/root, then exposing the information from Settings works fine. It's irrelevant to 99.9% of users either way. They're not going to be watching low-level process information, especially to the point that they would be able to spot something suspicious between all of the noise. It would be nice to have the information for other reasons, but there isn't much of a security argument for it.

The SELinux /proc restrictions and hidepid=2 also have nothing to do with higher level things like app usage statistics. There is no permission granting hidepid exceptions for apps. The information isn't available to Google apps. It's available to SafetyNet (snet) because it's part of the base system.

Daniel, you are getting away from the main issue. Security is not the subject we discuss. We do not have a disagreement on closing the security holes.
The issue however is very simple: Google closed the app usage information to third parties , even under user permission. I do not care if proc access was restricted or not . What I care though is that the only way left to extract that data has been disabled by Google, without providing an alternative way. This is killing legit businesses, and you cannot defend this action as there is still "something to improve"
Btw, I did not say Google apps can reach to /proc/. I said Google apps such as Play Store can reach app usage data. It does with a system permission, android.permission.PACKAGE_USAGE_STATS, and it is ON by default. Google has it, third parties don't under the same conditions as Google.
The violation to antitrust law is very clear. This info creates unfair advantages for Google's business, preventing third parties to have it and compete in a fair environment.
Solution is simple too. Google shall provide an API for app usage, with a clear user permission requirement obviously. This needs to be done immediately, before N gets commercial, so legit businesses should't lose revenue any single day.
And a suggestion to you based on  your comment with your own words : "a permission for viewing process information wouldn't be something users would understand" My friend, Google shall stop thinking they own the users, and comment on users' intelligence. Users can decide for themselves, they understand unlike you said what they give permission to.

@19

Third party apps are supposed not to know whether a third-party app even exists.
They should not have so many capabilities.
And this is privacy, you can refer to a very old iOS version.

@20

That is just ridiculous. An app with no permissions can get a list of installed applications.

This is NOT right. I mean legally not right..Fixing a security problem is one thing, revoking an accessibility/capability you allowed for years and let businesses run on it is another thing. The latter surely has legal consequences since serious financial implications will occur. And google should and will be held accountable for it.

I run a legit business with clear and well-accepted value proposition by end users. I have nothing to do with exploiting any security hole. So find another way to fix this damn whatever security hole is that you haven’t been able to fix for years with your army of developers.

@22

Unfortunately this is right.

The accessibility/capability allowed for years, do not suggest they should be accessable:

Android initially has no permission control mechanism,
While Blackberry have adopted it at the very begging, Apple have introduced it from iOS 6 which was released in Sep 2012.

Apple's AppStore makes sure an app cannot force user to grant a permission(by terminating itself after the user's deny).

The AppOpsManager class(the base part of the current runtime permission model) appeared in Android 4.3(July 2012), and it has not become available to end users until marshmallow(oct 2015).

What have Apple done in the 3 years?
Already have:
mandatorily full-disk encryption
strict sandboxing that apps not able to see each other/very limited shared data store

1, They disallowed access to deviceID/IMEI/device MAC, and provide several non
-persistent ids(app id, vendor id, adid) as replacement.

2, They made the iOS device to send randomized/fake MAC when the device is not connecting to a hotspot.

3, They import the activation protection to the iOS device.

4, They limit some APIs' capabilities to protect privacy:
   4.1 They limited visibility of shareable apps to limit installed app detection.
   4.2 They made face recognition process/data stored locally(Google photo does not).
   4.3 They have built a obscured analytics that individual telemetry data is mixed with noise.

Current Android have adopted(some are partially) nearly each one listed above.

So it is not even "accessibility/capability allowed for years",
it is actually a continues process that people are getting aware that "they should not be accessed".

"Fixing a security problem" and "revoking an accessibility/capability" are becoming the same thing, since logically you are not able to detect a security vulnerability before it occurs.

The change(separation and isolation) of the vulnerable mediaserver since Android 7 is a good example.

Moreover, some accessibility/capability have not been recognized as privacy involved:
Do a normal user(of course it is not you) understand that, if an app is allowed to scan nearby callular station id, wifi hotspot or bluetooth beacon, it is equivalently allowed to get pretty precise location information.

Are the average users able to take responsibility if their device opens up these sensitive accessibility?

Kelenchi, what you say is legally invalid! What you personally think is right legally is NOT right. Try to find a lawyer, who could tell you more about antitrust laws, which apparently does not fall in your expertise area. Yet you think you can make comments on it.

Btw, You do the same mistake. Average users are NOT stupid! Understand that once for all.

Giving the monopoly history of Apple and Google in your long message is NOT helping your case. Are you in a race with Apple to find out which one is going to be the most successful Monopoly?

Listen my friend, things need to change! Google and Apple ARE COLLECTING App Usage Information or several others regularly from user devices for years! They continue doing it with IOS 10, with Android N. Do not even try to deny it, These are facts. The court is always open to prove otherwise. But you can't, and we all know why.

What is Google or Apple? Government agencies, or commercial companies? We know it's the second one, right?  These companies create and UNFAIR COMMERCIAL ADVANTAGE for themselves, by not allowing competition. This is called MONOPOLY, and it is against ANTITRUST LAWS!!! There are billions of dollars behind this decision, advertisement money, which Google owns 39% of it!

Either Google should not collect the same info, or will allow the same for everyone, and LEAVE THE CONSENT TO THE USER. Otherwise is subject to antitrust laws, go and check your legal council.

You guys are very obviously Google employees, hidden behind gmail accounts. I expect an official explanation from Google. Not security hole explanations, an explanation to say why they did not provide an API attached to a clear user permission for app usage access, meanwhile they collect themselves. Google can reach me easily as you already have my gmail, know my office, my home, youtube selections, where I eat, what I search.....

By the way Kelenchi, the more I read your message, the more surprised I become.

One very important question to you!

Do you know what is private information in law, and how it can be collected? DON'T answer yourself.
Ask to a lawyer.

Your task as Google, as a platform developer, is to make sure there are no holes to support privacy laws. Not restrict data access, make sure that the access is done according to law.

@19

Did I miss something? Because https://developer.android.com/reference/android/app/usage/UsageStatsManager.html was not removed from Android N.

I too am not happy about restricted access to /proc as a developer, but I understand it from a user point of view. But you still can use the official App Usage API, can't you?

@26.

UsageStatsManager requires a System Level Permission. It is designed for system apps, like interestingly, Google Play app for example. The permission is ON by default.

If you are not a system app, you can still claim it, but it is OFF by default, because there is no User Permission attached to it. The user does not know if he/she has to do anything to activate it for your app.

That is practically, Google Play is able to collect the info, but user level apps can't.

There are a couple problems with UsageStatsManager. Two major problems are that it requires a special permission in Settings which some manufacturers have reportedly removed and your app needs to target API 21. I would be happy just getting a list of package names running on the device. I don't care about knowing if the running process is the foreground application. However, I know there are many apps that legitimately need this information. This will hurt small business. It sucks that malware has removed the legitimate usage of getRunningTasks, getRunningAppProcesses and now access to the filesystem and yet this will not stop the particular malware attack Tod demonstrated in his YouTube video.

@28.
This move is not targeting small businesses. They are just collateral damage. What the Google trolls cannot admit over here is much bigger. That is why you hear them covering the topic with security holes, which does not really fix main holes.

They are in fact targeting big advertisement giants like GroupM or alike, which tries to jump into Google's ad business in mobile. Huge money. Privacy or security are just useful tools for them to restrict access to useful info and save all for themselves.

What is hurt is the end user at the end of the day. They will loose many services coming from third parties. They are pushed more and more to the monopolies. That is why there is an antitrust law in this country, to protect end users towards high prices and moderate service levels.

Today I have installed 2 apps (Clean Master and Power Clean) from play store on my Android 7 device. They can collect running process without any permission. Can anyone tell me how they can collect running process with memory uses on CPU though Android N restricted the access of proc file.

@30, Those apps are using either:

1)  ActivityManager#getRunningServices
     https://developer.android.com/reference/android/app/ActivityManager.html#getRunningServices(int)
2) AndroidProcesses library
     https://github.com/jaredrummler/AndroidProcesses
     - Will not work on Android Nougat. Clean Master and Power Clean use getRunningServices on Nougat.

Is it possible that restrictions on accessing /sys also caused inability to read SD card serial ids ? This is a problem described here:

http://stackoverflow.com/questions/43484564/how-can-i-retrieve-an-sd-cards-serial-number-in-android-7-0

some apps use SD card serial id-s to build their licensing system. i.e. user can store some paid content on sd-card, and use it on many devices. To implement this a valid serial id of SD Card is a needed.

Is it possible that android.os.storage.StorageVolume.getUuid() should return such serial id ? in tests it appears to return some other value ( a label ? )

thanks.

Well this is crap!!!

This is exactly like if Windows would deny end users permission to Task Manager, Resource Monitor, and Process Explorer!  It is laughable!  It is unacceptable!

I'm absolutely shocked that this is where Android has gone now.

I too am totally shocked by this.  Every operating system since at least the mid 1990's has provided this ability.
This is huge mistake as pointed about by the System Panel developers.

This is an unacceptable change.

There MUST be a way for the owner of the phone to be able to see what is running on their phone and consuming resources.

I have been investigating an issue with Nougat on several phones for about 2 months now which seems to be related to Google services and battery usage but without this information and ability troubleshooting has been pretty much impossible.

It's getting worse. Since API level 26 (Android O, to be released) you cannot even access any more /prop/stat of your own process. In addition https://developer.android.com/reference/android/app/ActivityManager.html#getRunningServices(int) is being deprecated. Hereafter there is no way to know anything about any process running on a device.

This is so... bad. I saw a lot of applications on Google Play cannot work anymore because of this issue.

so much roundabout manipulation of how android works over the years is sad....

The way AppOps was withheld from end users until a bastardized version was cooked up that works make like an ultimatum type thing rather than simply denying permissions or feeding empty data.

...most of it reeks heavily of Google's data collection fetish and their opinion that we're all just stupid. The hostility towards user privacy and choice is so obvious it's not even funny.