On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote: > Here is the latest policy that I am using. Thanks for posting this. A few comments below. > diff --git a/device.te b/device.te > index 6424db6..08437a5 100644 > --- a/device.te > +++ b/device.te > @@ -23,6 +23,7 @@ type log_device, dev_type, mlstrustedobject; > type mtd_device, dev_type; > type mtp_device, dev_type, mlstrustedobject; > type nfc_device, dev_type; > +type nfc_ctrl_device, dev_type; Types are intended to be used as equivalence classes, so if the same set of domains are going to be allowed to access nfc_ctrl_device with the same permissions as for nfc_device, then just reuse nfc_device rather than introducing a new type. > diff --git a/domain.te b/domain.te > index 55c9ecd..88fb261 100644 > --- a/domain.te > +++ b/domain.te > @@ -85,6 +85,7 @@ if (in_qemu) { > allow domain sysfs:file rw_file_perms; > } > allow domain sysfs_writable:file rw_file_perms; > +allow domain sysfs_nfc_power_writable:file rw_file_perms; Likewise here, if you truly need to allow all domains rw access to this type, why not just reuse sysfs_writable? I was wondering though whether we truly should be allowing all domains such access. > diff --git a/file.te b/file.te > index 11c3ef6..ec7a02e 100644 > --- a/file.te > +++ b/file.te > @@ -8,6 +8,7 @@ type selinuxfs, fs_type; > type cgroup, fs_type, mlstrustedobject; > type sysfs, fs_type, mlstrustedobject; > type sysfs_writable, fs_type, sysfs_type, mlstrustedobject; > +type sysfs_nfc_power_writable, fs_type, sysfs_type, mlstrustedobject; See above. > @@ -43,6 +44,11 @@ type systemkeys_data_file, file_type, data_file_type; > type wifi_data_file, file_type, data_file_type; > type radio_data_file, file_type, data_file_type; > type nfc_data_file, file_type, data_file_type; > + > +type radio_nv_data_file, file_type, data_file_type; > +type efs_radio_nv_data_file, file_type, data_file_type; > +type radio_telephony_data_file, file_type, data_file_type; Do we need the distinction between radio_nv_data_file and efs_radio_nv_rdata_file? Where is that distinction used in the policy allow rules? > diff --git a/file_contexts b/file_contexts > index 92c6bb0..59bac40 100644 > --- a/file_contexts > +++ b/file_contexts > @@ -19,6 +19,16 @@ > /dev/block/loop[0-9]* u:object_r:loop_device:s0 > /dev/block/ram[0-9]* u:object_r:ram_device:s0 > /dev/block/mtdblock5 u:object_r:radio_device:s0 > +# rild needs access to the cdma and lte device nodes > +/dev/cdma_ipc0 u:object_r:radio_device:s0 > +/dev/cdma_rmnet5 u:object_r:radio_device:s0 > +/dev/lte_ipc0 u:object_r:radio_device:s0 > +/dev/lte_rmnet4 u:object_r:radio_device:s0 > +/dev/lte_boot0 u:object_r:radio_device:s0 > +/dev/lte_spi u:object_r:radio_device:s0 > +/dev/ttyGS1 u:object_r:radio_device:s0 > +/dev/lte_rfs0 u:object_r:radio_device:s0 You can shorten this specification by using pathname regexes, e.g. /dev/cdma_.* u:object_r:radio_device:s0 /dev/lte_.* u:object_r:radio_device:s0 /dev/ttyGS[0-9] u:object_r:radio_device:s0 > @@ -68,6 +78,7 @@ > /dev/tegra.* u:object_r:video_device:s0 > /dev/tty[0-9]* u:object_r:tty_device:s0 > /dev/ttyS[0-9]* u:object_r:serial_device:s0 > +/dev/ttyO3 u:object_r:nfc_ctrl_device:s0 > /dev/uinput u:object_r:input_device:s0 > /dev/urandom u:object_r:urandom_device:s0 > /dev/vcs[0-9a-z]* u:object_r:vcs_device:s0 > @@ -116,10 +127,24 @@ > /data/misc/wifi(/.*)? u:object_r:wifi_data_file:s0 > # App sandboxes > /data/data/.* u:object_r:app_data_file:s0 > + > +# rild needs access to the databases that the android telephony > provider manages > +/data/data/com.android.providers.telephony/databases(/.*)? > u:object_r:radio_telephony_data_file:s0 > +/data/data/com.android.providers.telephony/optable.db > u:object_r:radio_telephony_data_file:s0 > +/data/data/com.android.providers.telephony/databases/telephony.db > u:object_r:radio_telephony_data_file:s0 > +/data/data/com.android.providers.telephony/databases/telephony.db-journal > u:object_r:radio_telephony_data_file:s0 The first entry (with the (/.*)? suffix) should match the latter two entries already, making them unnecessary. > +# rild needs acess to radio image and associated md5 sum on userdata.img > +/data/radio/nv_data.bin u:object_r:radio_nv_data_file:s0 > +/data/radio/nv_data.bin.md5 u:object_r:radio_nv_data_file:s0 /data/radio/nv_data.bin.* would work here. > + > ############################# > # efs files > # > /efs(/.*)? u:object_r:efs_file:s0 > +# rild needs access to radio image and associated md5 sum on > /efs(/factory) ext4 image > +/factory/nv_data.bin u:object_r:efs_radio_nv_data_file:s0 > +/factory/nv_data.bin.md5 u:object_r:efs_radio_nv_data_file:s0 Likewise. Do we need the efs vs non-efs distinction? > diff --git a/seapp_contexts b/seapp_contexts > index c301792..52bbfa2 100644 > --- a/seapp_contexts > +++ b/seapp_contexts > @@ -32,6 +32,9 @@ isSystemServer=true domain=system > user=system domain=system_app type=system_data_file > user=nfc domain=nfc type=nfc_data_file > user=radio domain=radio type=radio_data_file > +user=radio domain=radio type=radio_telephony_data_file > +user=radio domain=radio type=radio_nv_data_file > +user=radio domain=radio type=efs_radio_nv_data_file > user=app_* domain=untrusted_app type=app_data_file levelFromUid=true > user=app_* seinfo=systemApp domain=trusted_app levelFromUid=true > user=app_* seinfo=systemApp name=com.android.browser > domain=browser_app levelFromUid=true You can only have one type= specification per user=, and this is only used by installd to label the /data/data/<packagename> directory and files when they are created. So the additional entries here should be no-ops effectively. We should likely add a validator program for seapp_contexts to check for these kinds of errors. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.