I propose workarounds for restrictions built in the "run-as" utility

[ChrysoliteAzalea]

Hello everyone!

Recently, I was researching the run-as utility pre-installed in the Android. It allows to run an arbitrary command in the context of an arbitrary package (kind of like sudo, but with apps instead of users). However, it has restrictions which seriously limit it usefulness -- the one I have the problem with, is that it does not accept packages which are not marked as debuggable. In this pull request, I solve this problem by tampering with the Android package list and marking the requested package as debuggable. This is done in a manner similar to the waydroid shell command, however, instead of running an arbitrary command, it will execute sed with a custom script that lists the given package as debuggable. After that, run-as accepts this package name.

Problems I've run into while making this PR

• sh may fail due to lack of controlling tty -- one of the possible solutions that worked for me was described in Issues opening waydroid shell #145
• run-as still conforms to other restrictions, for example, it will refuse to accept some system applications
• This workaround does not actually make the app debuggable -- it just tampers with the package list to make it appear as debuggable to libpackagelistparser (and to run-as). Unlike true debuggability, this one is not preserved across reboot or package installations and uninstallations -- the user may have to run this command again after container reboots or any changes to the package list.
• Since Android is designed for use with SELinux, run-as is unaware of AppArmor and will not switch to the necessary profile. All commands run with run-as will run under lxc-waydroid profile, and run-as is not able to run with android_app profile. In this pull request, I solve this by AppArmor policy amendment that introduces the fourth profile, run-as, designed specifically for this utility, in which execve on all binaries leads to transition to the android_app profile (it's just a modified copy of the lxc-waydroid profile (see below)

[ChrysoliteAzalea]

Ok, I will abstain from switching profiles into enforce mode here, as it's already proposed in #906 .

If that PR will get merged before this, I'll make changes here accordingly.

[ChrysoliteAzalea]

Well, I've run into something interesting in the way run-as works. On Waydroid, it doesn't set supplementary groups, so any command run with it is denied access to /storage/emulated/0 even if the app it runs as is allowed it (regardless if I run it as an actually debuggable app, or as a "fake-debuggable" set through waydroid make-debuggable). On my tablet, however (that runs stock unrooted and unmodified Android), commands run with run-as have more permissions than the app (I run them as Termux app), for example, it has access to /storage/emulated/0 even if the app is denied such access, and it has more supplementary group than commands run from the app have.

[ChrysoliteAzalea]

I've looked how run-as works with debuggable packages on an actual smartphone (with stock Android, non-rooted), and I'm not sure whether AppArmor policy amendments are necessary. On actual smartphones, run-as changes UID, GID and SELinux context to match the target app, but it does not clear the capability bounding set, load seccomp filter, and the supplementary groups differ from those expected of a target app (for example, the run-as command may still have access to the shared storage even if the app is denied it). Moreover, there are already proposed amendments -- I think I'll remove it from this pull request. If necessary, they can be proposed in another pull request.

[ChrysoliteAzalea]

Closing this PR in favor of patching the run-as utility itself.