[Security Improvement Suggestion] Fingerprint Authentication

[mvastola]

Describe your problem.

NB: So this issue is a request for a security improvement. This is obviously arguably a feature request, but given the fact it's a security enhancement and (I imagine) pretty trivial to implement, I thought it might be allowed here since -- even if the maintainers don't have the time/desire to do so -- it being listed might serve as an invitation for others to make a PR. (Unfortunately I don't have the experience developing for mobile/android to do so myself.) Obviously feel free to close this if it's not welcome.

The suggested change is quite basic: add a dialog/action for fingerprint/face/PIN (whatever the user chooses) authentication in the KernelSU app and (potentially optionally) require it before performing certain superuser actions. This is also the only place I can think of where KernelSU lacks feature parity with Magisk.

There are several places where this could be used, all of which would help mitigate the sizeable security risks of running root on your phone:

• As a requirement to become root (using su) in adb
  This is probably the most important use case. KernelSU takes good care to disable access su in adb by default and counsel users against globally/permanently enabling it when installing KernelSU, but people who root their phones are likely to need/want to use their root access via adb sooner or later.

  And, once it's enabled (either via enabling the setting to run adbd as root, or via the more secure route of granting superuser access to com.android.shell), it is very easy to forget to disable it. Even if users properly disable it as soon as they're done, the existence of wireless adb and the possibility a user's computer is compromised in the first place means that an attack can take place concurrent with authorized use.

  If the setting to run adbd as root is active, there is also the added attack surface of a vulnerability in adbd itself being exploited before usb authorization is enforced (and therefore bypassing it). Requiring on-device interactive authentication by fingerprint or similar as a prerequisite to becoming root every time su is invoked in adb is a straightforward way to obviate these security risks.

  This would also make it possible to actively prompt the user to enable superuser for com.android.shell as soon as an attempt is made to execute su. Currently, the su binary is hidden until/unless a user takes the initiative to navigate to, and manually enable, superuser for com.android.shell. Even worse, because the link between com.android.shell and adb is somewhat obscure knowledge that many users won't know, such users are much more likely to use the easier-to-locate yet unneeded and more dangerous option of running adbd as root.

  Instead, with su placed behind fingerprint authentication, the setting to run adbd as root could be heavily discouraged or perhaps even removed. If there is a need to preserve the ability to run adb as root in situations where it is specifically needed, a possibility is removing the adbd as root setting and enabling the adb root command, contingent on the same fingerprint authentication. Even on development devices, the requirement to run adb root to opt-in to running adbd as root is something even Android enforces natively due to the security risks created by the alternative.

• When using su from terminal emulator apps (e.g. termux)
  Terminal access as root is incredibly powerful, but also perhaps the easiest way for an attacker with temporary physical access to an unlocked device to quickly compromise it before the owner even has time to notice.

  Authorization could be required either once per su invocation, or tied to the lifetime of the su invoker's PID.

• As a requirement before any superuser capabilities are granted to an app
  It varies on an app-by-app basis how much damage can be done in an app with superuser access. As mentioned, adb or a terminal emulator can be easily used for nefarious purposes. By contrast, a module/app like PixelXpert would be much more difficult to use nefariously.

  In any case, the natural extension of the previous use cases is to make the need for authorization configurable on a per-app basis.

• As a requirement to making changes to KernelSU
  For any of the preceding to be effective, at a minimum, the ability to disable fingerprint authentication or loosen its restrictions must be itself placed behind fingerprint authentication.

  Ideally, however, any non-read-only access to the KernelSU app or CLI should require authentication. If there is no need to preserve read-only access, doing this could be as simple as requiring fingerprint authorization upon opening the app.

  This can be done before and separate from any of the other changes above, and still offer a security benefit.