Add selinux policies to the buildroot examples

[jonsmirl]

Since optee is all about security, it would make sense to provide a build option to lock the demo buildroot examples down using selinux. This would serve two purposes - provide a reference to a basic framework of locking down buildroot. And second, it could show how to lock down which user space apps can communicate to a specific TA.

For example, I'm working on an embedded system, I don't want my app running as root. So I need to figure out how to ensure that my app is the only thing that can talk to its associated TA. I'm guessing that this can be controlled by selinux policies? I can't locate any examples of doing this.

[jforissier]

Hi @jonsmirl ,

Client apps do not need to be run as root. The root FS generated by buildroot has a "test" user and sets appropriate permissions on the TEE device. Please check that.
As for selinux, I must admit and don't know much about it (read: I have never written rules etc.) but what you are proposing seems useful.

[jonsmirl]

Not needing root without selinux controlling which apps can use the device means that any user in the right group can interact with your TA. In my case the TA has the private encryption key for a secure connection, I need to make sure another app can't ask the TA to encrypt something using that key.

I think there is a way to set the tee device so that normal users can get to it, and then use selinux to deny app apps except ones on its list. I am in control of the installed apps, I just want to protect against some new app getting installed by a hack.

[jforissier]

any user in the right group can interact with your TA

Correct.

I just want to protect against some new app getting installed by a hack.

One use case I can think of, for which you probably would not need selinux, is your client app is a daemon spawned by root, and running as the tee user. Similar to tee-supplicant. In this case the tee user account can be locked, and it would be enough to ensure that only your app can invoke the TA.

But selinux is certainly useful for finer-grained control.

[vchong]

We have some basic rules written for the reference hikey aosp build [1][2] but not sure how well they'll transfer over to linux.

[1] https://android-review.linaro.org/c/device/linaro/hikey/+/20090/22/sepolicy/file_contexts
[2] https://android-review.linaro.org/c/device/linaro/hikey/+/20090/22/sepolicy/tee.te

[jbech-linaro]

In my case the TA has the private encryption key for a secure connection, I need to make sure another app can't ask the TA to encrypt something using that key.

This is a really tricky problem to resolve. In the end the trust model for TrustZone is that we do not trust anything coming from normal world. Depending on use case it doesn't matter sometimes, but other times it's a real problem. The things you're describing are quite challenging to implement. Using SELinux or something similiar to harden things helps a bit (as long as there is not root exploit). In addition, it'd also be good if the non-secure user apps could authenticate themselves, so the TA itself can decide if it is going to serve the caller or not. But doing authentication like that when only using the device itself isn't easy, since you cannot easily store secrets in non-secure world. On the other hand if the authentication request comes from outside, then it's more doable, since that could eventually come from a shared key or an asymmetric key (i.e., known to the TA, the one on the other side of the network, but unknown the non-secure side in the device itself).

I'm all in favor of leveraging other security solutions that hardens things, so if you can come up with a proof of concept working with our Buildroot setup and QEMU for example, then I wouldn't mind to merge it (compile time flag is needed of course so it's easy to enable and disable it).

[jonsmirl]

I don't see an obvious solution to this, what's the point in having the TA if the embedded device can't secure who is calling the TA? Is the TA any better than just putting the private key in a file and using permissions to secure it?

This problem is going to be replicated millions of times with all of the devices being built to talk to AWS IOT, Azure, Google, Baidu, etc. Might be a good topic for a white paper from Linaro on security best practices for an embedded system. There are very few people around with the knowledge needed to combine selinux, TAs and other security tools without leaving holes.

[jbech-linaro]

Might be a good topic for a white paper from Linaro on security best practices for an embedded system.

That's a good suggestion and I'll see if we can come up with anything like that in the future. Having that said, Arm are doing lots of work with PSA across all sorts for market segments. I don't think they are touching the particular question in this thread, but otherwise PSA is a pretty good start when looking for guidance on how to implement security on a device.