Android O: Permission denied on /proc entries for htop and top

[jwhipp]

I'm testing the Android O Dev Preview and I've found some up-coming issues with Termux to put on the radar for Android O compatibility.

Utilities that read /proc (top, htop, etc.) are not working in Termux.

Examples:

htop: Cannot open /proc/stat: Permission denied
top: can't open 'stat': Permission denied

I'm guessing this is due to further locked down SELinux in Android O.

[ghost]

This is not an issue with Termux. Starting in Android Nougat, apps are no longer allowed to see running processes.

[jwhipp]

This issue is different, in Nougat, htop and associated tools can see processes in the current shell, but not all as we know. In Android O, access is denied to /proc entries making these tools completely broken. See the report output, this is not an issue on Nougat.

[ghost]

This would mean rewriting top and other tools, and I'm not even sure it'd be possible then.

[jwhipp]

Looks like a permission request issue to me. My guess is O exposes some new permission schemes that needed to be adapted to.

[ghost]

Why would there be permission in the API for reading running processes? Pretty useless imo.

[fornwall]

From an issue on the Google issue tracker:

Status: Won't Fix (Intended Behavior)
Thank you for filing this bug report.

The removal of /proc/stat was intentional. /proc/stat leaks side channel information about applications which could allow one application to infer the state of other applications on the device. See https://www.cl.cam.ac.uk/~lmrs2/publications/interrupts_pets16.pdf for example.

So this is indeed an intended change in Android 0.

[iammer]

Will this effect ps and killall as well?

[ghost]

@iammer Yes as they use the same thing.

[jwhipp]

Here's the background on what's going on with this:

https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html

Of course, Google in their infinite wisdom gives no opt-in work around besides flashing a custom kernel which does not have seccomp.

[iammer]

Is it just /proc/stat that is being removed or the entire /proc ? I ask since my main concern is being able to kill daemon processes I have started. I.E killall sshd. Just killing the main Termux process won't kill these, and I don't want to leave them hanging around in the background.

EDIT: After some testing, I guess the daemon processes are killed eventually just takes some time.

[h6y3]

I think the issue I just filed may be related to this #414. In my case, I use RVM with termux and the script calls ps

[Alexander--]

@jwhipp I don't think, that this has anything to do with seccomp. I just checked, and switching SELinux mode to permissive allowed me to view /proc/ contents without restrictions (aside, of course, from restrictions of hidepid).

Seccomp is commonly used to ban entire system calls, which should be of no interest to apps. Seccomp rules can be used to dynamically sandbox specific system calls by combining it with ptrace, but doing so is more computationally expensive and less robust, compared to SELinux rules. I doubt, that seccomp might be used for securing individual directories by Android developers or anyone else, when they have SELinux.

[kstoykov]

There are applications showing system information, like CPU usage and so. Without access to /proc/stat they are dead.... What are uses that do not use their phone just for calls/facebook/mail supposed to do? Isn't there any API to avoid this stupid limitation?

I'm really pissed off by last Android versions.... restrictions, restrictions. With each version is going to be more "iOS" like which is terrible.

[ghost]

@kstoykov Secure = iOS like?

[jwhipp]

@Alexander-- That information was based on digging from XDA which led me to the Android developer blog on the subject.

From the linked Article:

"Android O includes a single seccomp filter installed into zygote, the process from which all the Android applications are derived. Because the filter is installed into zygote—and therefore all apps—the Android security team took extra caution to not break existing apps. The seccomp filter allows:
all the syscalls exposed via bionic (the C runtime for Android). These are defined in bionic/libc/SYSCALLS.TXT.
syscalls to allow Android to boot
syscalls used by popular Android applications, as determined by running Google's full app compatibility suite
Android O's seccomp filter blocks certain syscalls, such as swapon/swapoff, which have been implicated in some security attacks, and the key control syscalls, which are not useful to apps. In total, the filter blocks 17 of 271 syscalls in arm64 and 70 of 364 in arm."

How did you manage to turn SELinux off with out root? Reason I say that is root -should- be allowed to to /proc even with seccomp enabled. The test would be access to /proc with out root. I still think Google should've found a way to disable with developer options.

@kstoykov - You have two choices. 1 - Root, 2 - Install a kernel that does not have seccomp

[RupankarGhosh]

does vtop works in Android O termux? node module use also process like vtop...and what about Glances?

[Alexander--]

@jwhipp

Reason I say that is root -should- be allowed to to /proc even with seccomp enabled.

Indeed, daemonsu gets started during early boot by init, so it does not suffer from seccomp restrictions, imposed upon Zygote-based apps. But I specifically tested without root (I used root to disable SELinux, then checked from ordinary UID).

The article you linked to has no indication that seccomp has any bearing on /proc. Virtual /proc files aren't "system calls", they are part of virtual filesystem (procfs). And filesystem files are traditionally secured via SELinux. The issue is not entirely clear until someone looks up relevant SELinux rules, but I am going to stay by my opinion for now.

[kstoykov]

After a day of reading I can totally agree that reading a file from virtual file system is not a "system call". Where should be something else why such reads are disabled. Also reading data for CPU frequency is disabled as well.

Anyway Google wants it that way and we can't do anything.... "Security after all", right? Stating to think why do I have to pay $600 for high-end device and then use it as old Nokia 3310 + facebook, instead of using them as computers which they really are... So disappointed....

[jwhipp]

Ok so I think what we need a good list of what works and doesn't with just SELinux in permissive or disabled.

@Alexander-- What ROM/device? I'd love to try it, I'm on a Pixel XL stock.

Another thing to remember is that some of these tools make system calls as well as read /proc. With out looking at the ps/top/htop code I am not sure to what extent.

[Alexander--]

@kstoykov

Yup, they have totally gone nuts with curtailing access to /proc contents. Even /proc/filesystems is restricted (no idea what kinds of leaks they are trying to prevent that way). Only bare minimum, required for existing AOSP code, was kept. Of course, since they have chosen a whitelist approach, the possibility of people using new /proc APIs in future is also reduced... They are effectively abandoning practical Linux compatibility.

@jwhipp

try with Android emulator (no idea if setenforce still works on physical Android devices).

You can gain some insight into specific restrictions even without viewing SELinux rules, just run

ls -Z /proc/

via adb (-Z enables display of SELinux metadata). This gives quite clear view of what is still usable.

[kstoykov]

I suppose that with future security restriction will be more and more, anyway LineageOS ftw, root ftw :)

[darkgeek]

Well, is it possible to use proot to intercept any calls to /proc, and translate to our own implemented faked /proc?

[ghost]

I think we would just have to recompile every binary with a fake proc path eg /data/data/com.termux/files/emuproc

[darkgeek]

@V0idSt4r Yes, I think so, but it's too tricky and difficult to implement a full userland fake /proc, to be honest.

[brauliobo]

How to use htop as root? Termux doesnt even find it

[Root-voidX]

Htop is working on android 8.0 on my Galaxy S9+. Its able to read all processes within termux. But I notice it read my ram as out of 4.98gb when the device has 6gb.

[edenist]

How to use htop as root? Termux doesnt even find it

You can run htop as root using the 'tsu' utlity.

$ pkg install tsu

Then to run, drop to root shell, set your TERM envvar, then you can run it as before.
$ tsu
$ export TERM=xterm-256color
$ htop

Still experiencing this on Lineage 15.1 on both Lenovo Tab 3 plus and Nexus 6. Going from the info here, the workaround above is going to be the only way to resolve on most devices.

[ghost]

Issue solvable either via setenforce 0 or running program under "tsu". Both variants require device to be rooted, of course.

Variants like "faked" /proc are wontfix. Though, it is doable by supplying fake "/proc/stat" file via proot, but this will make top/htop produce fake output.

[Kaktsus]

szkoda że google takie rzeczy robi
(sorki za pisanie nie po angielsku ale zbyt nie potrafię)

[kotoOo]

Any updates on this gentlemen? Why the issue is closed even? Don't you guys think that a Linux without ps is good enough? Is there a solution nowadays how to make ps command working under Termux/Ubuntu?

[ghost]

how to make ps command working under Termux/Ubuntu?

You need to bind mount fake proc uptime stat if using ps command

proot-distro already handles this one including Andronix as well but missing both loadavg and uptime for other process viewing utilities

It seems this will be used as default bind mounts on proot helpers out there

[ghost]

@kotoOo Of issue is closed, then perhaps there is a reason maybe?

Android restrictions (security hardening) is NOT a subject for attempting to be bypassing (this isn't possible without rooting) or workarounds in Termux-wide scope. Under proot you can still use fake /proc entries like @wmcb-tech suggested. But as they are fake, functionality of proc viewing tools would be limited.