platform_system_sepolicy/public/tee.te

##
# trusted execution environment (tee) daemon
#
type tee, domain;

# Device(s) for communicating with the TEE
type tee_device, dev_type;

allow tee fingerprint_vendor_data_file:dir rw_dir_perms;
allow tee fingerprint_vendor_data_file:file create_file_perms;
Trusted Execution Environment policy. 2012-08-13 12:09:39 +02:00			`##`
			`# trusted execution environment (tee) daemon`
			`#`
Move TEE rules to vendor image "tee" domain is a vendor domain. Hence its rules should live on the vendor image. What's left as public API is that: 1. tee domain exists and that it is permitted to sys_rawio capability, 2. tee_device type exists and apps are not permitted to access character devices labeled tee_device. If you were relying on system/sepolicy automatically labeling /dev/tf_driver as tee_device or labeling /system/bin/tf_daemon as tee_exec, then you need to add these rules to your device-specific file_contexts. Test: mmm system/sepolicy Test: bullhead, angler, and sailfish boot up without new denials Bug: 36714625 Bug: 36714625 Bug: 36720355 Change-Id: Ie21619ff3c44ef58675c369061b4afdd7e8501c6 2017-04-03 20:05:45 +02:00			`type tee, domain;`
tee domain is a vendor domain As a result, Keymaster and DRM HALs are permitted to talk to tee domain over sockets. Unfortunately, the tee domain needs to remain on the exemptions list because drmserver, mediaserver, and surfaceflinger are currently permitted to talk to this domain over sockets. We need to figure out why global policy even defines a TEE domain... Test: mmm system/sepolicy Bug: 36601092 Bug: 36601602 Bug: 36714625 Bug: 36715266 Change-Id: I0b95e23361204bd046ae5ad22f9f953c810c1895 2017-03-29 06:59:24 +02:00
Move TEE rules to vendor image "tee" domain is a vendor domain. Hence its rules should live on the vendor image. What's left as public API is that: 1. tee domain exists and that it is permitted to sys_rawio capability, 2. tee_device type exists and apps are not permitted to access character devices labeled tee_device. If you were relying on system/sepolicy automatically labeling /dev/tf_driver as tee_device or labeling /system/bin/tf_daemon as tee_exec, then you need to add these rules to your device-specific file_contexts. Test: mmm system/sepolicy Test: bullhead, angler, and sailfish boot up without new denials Bug: 36714625 Bug: 36714625 Bug: 36720355 Change-Id: Ie21619ff3c44ef58675c369061b4afdd7e8501c6 2017-04-03 20:05:45 +02:00			`# Device(s) for communicating with the TEE`
			`type tee_device, dev_type;`
Fingerprint data is now stored in one of two ways depending on the shipping API version: For devices shipped before Android P nothing changes, data is stored under /data/system/users/<user-id>/fpdata/... Devices shipped from now on will instead store fingerprint data under /data/vendor_de/<user-id>/fpdata. Support for /data/vendor_de and /data/vendor_ce has been added to vold. Bug: 36997597 Change-Id: Ibc7cc33b756f64abe68a749c0ada0ca4f6d92514 Test: manually 2018-01-22 22:24:10 +01:00
			`allow tee fingerprint_vendor_data_file:dir rw_dir_perms;`
			`allow tee fingerprint_vendor_data_file:file create_file_perms;`