New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does an Android app requires ROOT privilege to run a TA? #903

Closed
toddkuhreng opened this Issue Jul 6, 2016 · 15 comments

Comments

Projects
None yet
7 participants
@toddkuhreng

toddkuhreng commented Jul 6, 2016

Hi

I am trying to build a trusted application that could be used by my Android application; however, I am stuck with permission errors. When I execute the normal world component of the trusted app through Android app, I am an error as following:

./tee_rsacrypt: NW: TEEC_InitializeContext failed with code 0xffff0008

prem _eeror

  • u0_a55 is the user id of the Android app that trying to run this trusted app

When I execute this binary (NW component of TA) with root permission through ADB shell, yes it works. So does that means TA can only be used by a Android application that has root privilege? If so, how can a normal Android application (which don't have root privileges) can run a TA? There should be way, right?

Thank you so much for your time.

@hoihochan

This comment has been minimized.

hoihochan commented Jul 7, 2016

You need elevated permission to write to /dev/optee00armtz, that's why it fails.

@d3zd3z

This comment has been minimized.

Contributor

d3zd3z commented Jul 7, 2016

Yes, and this is an open issue. The permission on the tee devices is determined by both file permissions and SELinux (for non debug builds). The problem is that we don't have any mechanism currently in place to map the device nodes to specific trusted applications. Thoughts on a good Android-like way of handling this are greatly appreciated.

@toddkuhreng

This comment has been minimized.

toddkuhreng commented Jul 8, 2016

Hi @d3zd3z ,

Sorry, I didn't understand your response. Could you please elaborate a bit on this?

So I understand there are two devices /dev/tee0 and /dev/teepriv0. tee-supplicant will communicate with /dev/teepriv0 and my TA client is communicating with /dev/tee0. Looks like both needs root privilege to access this device. Even with system privilege I cannot run run tee-supplicant or my TA client app.

I am using hikey_userdebug build, so SELinux is in permissive mode. Hence, for now SELinux is not creating issue. I understand in production build (SELinux), we have to write a policy or something. For my debug build what could be easiest hack that I can do to run this native binary (TA client) from my Android app ?

Most confusing thing for me is that why do we need root privilege to run tee-supplicant or ta_client? System privilege should be fine, right? No process in Android runs with root privilege. Highest privilege Android got is system privilege, I think. Please correct me, if am wrong.

Any pointers, any suggestions to fix this? I am ready to work on this, but please help me to understand this problem better.

Thank you so much for your time.

@d3zd3z

This comment has been minimized.

Contributor

d3zd3z commented Jul 8, 2016

It's just based on unix permissions on the device node. They are currently set to require root permissions to access. Just allowing other users to have access to the device nodes would then allow any client to do fairly arbitrary things with the TAs.

There are two common approaches. One is to open the devices as root, and then drop the root privileges. This is somewhat discouraged in Android, because if you get it wrong, and can lead to a root exploit.

The other approach is to make the device nodes more generally accessible, but enforce more stringent control at the driver level. The problem is that the driver doesn't initially know what TA is going to be accessed, which is why I was soliciting for ideas on how to better handle this.

@toddkuhreng

This comment has been minimized.

toddkuhreng commented Jul 12, 2016

Hi @d3zd3z ,

Thank you so much for explaining. As you mentioned, I think for Android we should make the device nodes more generally accessible, but enforce more stringent control at the driver level( or maybe optee core level?)
If I understood correctly, first TA calls TEEC_InitializeContext(NULL, &ctx) to initialize the context and then it calls:

TEEC_OpenSession(&ctx, &sess, &uuid, TEEC_LOGIN_PUBLIC, NULL, NULL, &err_origin);

This is when it communicates to TEE_CORE for the first time and tee core will load the corresponding TA. So, if tee core can somehow validate the client when client calls TEEC_OpenSession, it should be fine, right?

Anyways, I am currently experimenting with this and am stuck. Could you help me with following problem that I am facing:

Currently, the permissions on the devices as follows:
permissions

I would like to give read and write permission to Android 'system' user also. How do I do that?
Looks like there are no udev rules for Android to set device node (/dev/tee0) access permission such a way it is accessible to all android apps.

Thanks again,

@d3zd3z

This comment has been minimized.

Contributor

d3zd3z commented Jul 12, 2016

Have a look at device/linaro/hikey/ueventd.hikey.rc. It's a lot more simplistic than udev, but should at least let you make the device nodes writable. The init.hikey.rc file would also be a place to start up the supplicant.

@jbech-linaro

This comment has been minimized.

Contributor

jbech-linaro commented Sep 15, 2016

This ain't an issue any longer or?

@jbech-linaro

This comment has been minimized.

Contributor

jbech-linaro commented Nov 3, 2016

There are two patches, they are abandoned for another reason, but they should resolve the issue you've been facing.

Abandoned commits:
https://android-review.googlesource.com/#/c/292345/
https://android-review.googlesource.com/#/c/295569/

Can now be found here if you would like to try it out:
https://github.com/kuscsik/linaro-hikey/tree/android-hikey-linaro-4.4-optee
https://github.com/kuscsik/device-linaro-hikey-1/tree/aosp_optee

We have decided where to best have those patches, we would like to get it merged to the official AOSP tree, but it's not straight forward to do so, since we're not the ones deciding what to accept there. So, as of now this is living as loose patches.

Based on that and the other answers in this issue I'm going to close this issue.

@acalb

This comment has been minimized.

acalb commented Mar 20, 2017

Hi,

I am trying to call my TA from an Android application but I am also stuck with permission errors.
I am using @vchong 's manifest: https://github.com/vchong/optee_android_manifest

AOSP: 7.1.1
Kernel Version: 4.9.10

I have applied the patches in abandoned commits mentioned above, however tee-supplicant is still not accessible without root permission. Any help would be very much appreciated.

Thank you so much for your time.

@vchong

This comment has been minimized.

Contributor

vchong commented Mar 20, 2017

@acalb

Please use https://github.com/linaro-swg/optee_android_manifest/tree/hikey-n-4.9.

tee-supplicant still has to be started as root atm due to ongoing permission/selinux issues. If you use above build, it will be started for you automatically as root on power up so you don't have to worry about it.

If you have access to the console or adb shell and want to do a quick test to see if things will work eventually in the build you're currently running, kill the running tee_supplicant process and start tee_supplicant as root. Then call the TA from NW (not apk) app.

As for calling TAs from a NW app, try adding below to device/linaro/hikey/sepolicy/file_contexts and rebuild.

/path/to/your/NW/app u:object_r:tee_exec:s0

Please note that this is not the be-all and end-all for everything. Depending on what you (or your TA) wants to do, you'll most probably still need to add more SELinux rules to your build.

@acalb

This comment has been minimized.

acalb commented Mar 21, 2017

@vchong

Firstly, thank you so much for your response.

I tried adding my NW app to /device/linaro/hikey/sepolicy/file_contexts. However, it still needs root privilege to run my app. After adding NW app path(/system/bin/tee_helloworld) to file_contexts, it doesn't recognized in adb shell without root privilege. I took screenshot of both scenarios. Is it possible to successfully run my NW app without root privilege?

Without root privilege;

screenshot from 2017-03-21 09 01 19

Root privilege:
screenshot from 2017-03-21 09 02 19

NW app path added to file_contexts + root privilege:
screenshot from 2017-03-21 09 16 32

NW app path added to file_contexts + no root privilege:
screenshot from 2017-03-21 09 15 44

@vchong

This comment has been minimized.

Contributor

vchong commented Mar 21, 2017

If you're only trying to run helloworld, then no need to add it to file_contexts.
What is the output of running command ls -l /system/bin/tee_helloworld?
Please try below after booting up and let us know if it works.

su
killall tee-supplicant
tee-supplicant &
exit
tee_helloworld
@acalb

This comment has been minimized.

acalb commented Mar 21, 2017

Actually I have another NW apps like helloworld application and all of them are working in root privileges.
However, without root privileges, all of them are giving the same output "TEEC_InitializeContext failed with code 0xffff0008".
TEEC_ERROR_ITEM_NOT_FOUND according to GP TEE Client API.

Output of ls -l /system/bin/tee_helloworld
screenshot from 2017-03-21 11 08 06

Output of tee_helloworld
screenshot from 2017-03-21 11 06 20

@jbech-linaro

This comment has been minimized.

Contributor

jbech-linaro commented Mar 21, 2017

I'm not sure if I'm doing a disfavor by replying here, since I don't really have time to support in short term with follow up questions. But besides running with the GP Socket tests disabled (which currently doesn't work as non-root), I've been able to run everything successfully as shell : shell in AOSP on HiKey. I started to look into this a couple of weeks ago, but has been a bit side tracked since then. My intention is to follow it up as soon as I have some time left over. In the mean time I think @vchong has been able to make a rather stable setup, that is why I have avoided chiming in here.

Anyhow, if you want to check my tree and SELinux settings etc, feel free to have a view at my "work in progress" branches (basically running latest on everything, AOSP, OP-TEE etc...).
https://github.com/jbech-linaro/optee_os/tree/aosp-optee-4.9
https://github.com/jbech-linaro/optee_android_manifest/tree/aosp-optee-4.9
https://github.com/jbech-linaro/device-linaro-hikey/tree/aosp-optee-4.9
https://github.com/jbech-linaro/optee_client/tree/aosp-optee-4.9
https://github.com/jbech-linaro/optee_test/tree/aosp-optee-4.9
https://github.com/jbech-linaro/optee_android_tools/tree/kernel49

Again, those needs to be cleaned up and .. I won't have time to neither do the clean up nor support for a week or two, but still it might give you some ideas.

edit
As @vchong pointed out, I'm running with SELinux disabled (permissive mode) right now, which probably is why I haven't seen the issues yet. So, meanwhile we're working on the SELinux rules etc, then you can try the same.

@vchong

This comment has been minimized.

Contributor

vchong commented Mar 21, 2017

@acalb Sorry, you're right. I got confused going back and forth between the 2 builds. Please stop using https://github.com/vchong/optee_android_manifest and rebuild from scratch using https://github.com/linaro-swg/optee_android_manifest/tree/hikey-n-4.9. BUT before rebuilding, add helloworld and friends to file_contexts as instructed above. Adding them to your current build will not help!

In any case, for your current build, as @jbech-linaro mentioned above, if you can't run helloworld and friends as root, the hack is to disable selinux.

su
setenforce 0

Or make this change permanent based on @jbech-linaro's repo above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment