* SE Android on Galaxy Nexus
@ 2012-03-02 15:29 Subramani Venkatesh
2012-03-02 15:39 ` Stephen Smalley
0 siblings, 1 reply; 14+ messages in thread
From: Subramani Venkatesh @ 2012-03-02 15:29 UTC (permalink / raw)
To: selinux
Hi,
I got SE Android working on Galaxy Nexus, followed instructions from
http://selinuxproject.org/page/SEAndroid
After executing "setenforce 1", launching applications works as
expected, but it is only short period of time, later it reboots. Would
like to debug the issues, Is their any guide to debug SE on Android?
Regards,
Subbu
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 15:29 SE Android on Galaxy Nexus Subramani Venkatesh
@ 2012-03-02 15:39 ` Stephen Smalley
2012-03-02 16:03 ` Subramani Venkatesh
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Smalley @ 2012-03-02 15:39 UTC (permalink / raw)
To: Subramani Venkatesh; +Cc: selinux
On Fri, 2012-03-02 at 10:29 -0500, Subramani Venkatesh wrote:
> Hi,
> I got SE Android working on Galaxy Nexus, followed instructions from
> http://selinuxproject.org/page/SEAndroid
> After executing "setenforce 1", launching applications works as
> expected, but it is only short period of time, later it reboots. Would
> like to debug the issues, Is their any guide to debug SE on Android?
Did you try the policy changes posted by Bryan Hinton for the Galaxy
Nexus? See:
http://marc.info/?l=selinux&m=132752617008734&w=2
Before running setenforce 1, you should check for any avc messages in
your dmesg output, e.g.
adb shell dmesg | grep avc
Such denials need to be addressed through policy changes or labeling
changes before you go to enforcing mode.
You might want to start a process capturing dmesg output just before you
go to enforcing mode, e.g.
adb shell su 0 cat /proc/kmsg
adb logcat *:E can also be helpful.
--
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 15:39 ` Stephen Smalley
@ 2012-03-02 16:03 ` Subramani Venkatesh
2012-03-02 17:51 ` Bryan Hinton
0 siblings, 1 reply; 14+ messages in thread
From: Subramani Venkatesh @ 2012-03-02 16:03 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
Thanks Stephen,
I did not add Bryan changes, i will add them now and see the difference.
Thanks for debug information.
Regards,
Subbu
On Fri, Mar 2, 2012 at 10:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2012-03-02 at 10:29 -0500, Subramani Venkatesh wrote:
>> Hi,
>> I got SE Android working on Galaxy Nexus, followed instructions from
>> http://selinuxproject.org/page/SEAndroid
>> After executing "setenforce 1", launching applications works as
>> expected, but it is only short period of time, later it reboots. Would
>> like to debug the issues, Is their any guide to debug SE on Android?
>
> Did you try the policy changes posted by Bryan Hinton for the Galaxy
> Nexus? See:
> http://marc.info/?l=selinux&m=132752617008734&w=2
>
> Before running setenforce 1, you should check for any avc messages in
> your dmesg output, e.g.
> adb shell dmesg | grep avc
>
> Such denials need to be addressed through policy changes or labeling
> changes before you go to enforcing mode.
>
> You might want to start a process capturing dmesg output just before you
> go to enforcing mode, e.g.
> adb shell su 0 cat /proc/kmsg
>
> adb logcat *:E can also be helpful.
>
> --
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 16:03 ` Subramani Venkatesh
@ 2012-03-02 17:51 ` Bryan Hinton
2012-03-02 19:31 ` Stephen Smalley
2012-03-02 20:26 ` Stephen Smalley
0 siblings, 2 replies; 14+ messages in thread
From: Bryan Hinton @ 2012-03-02 17:51 UTC (permalink / raw)
To: Subramani Venkatesh; +Cc: Stephen Smalley, selinux
Here is the latest policy that I am using.
From: Bryan Hinton <bryan@bryanhinton.com>
Date: Wed, 15 Feb 2012 22:31:58 -0600
Subject: [PATCH] New SEPolicy for SCH-1515.
---
device.te | 1 +
domain.te | 1 +
file.te | 6 ++++++
file_contexts | 26 ++++++++++++++++++++++++++
nfc.te | 1 +
radio.te | 3 ++-
rild.te | 7 +++++++
seapp_contexts | 3 +++
8 files changed, 47 insertions(+), 1 deletions(-)
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;
type nv_device, dev_type, mlstrustedobject;
type powervr_device, dev_type, mlstrustedobject;
type ptmx_device, dev_type, mlstrustedobject;
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;
# Read access to pseudo filesystems.
r_dir_file(domain, proc)
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;
type inotify, fs_type, mlstrustedobject;
type devpts, fs_type;
type tmpfs, fs_type;
@@ -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;
+
# /data/data subdirectories - app sandboxes
type app_data_file, file_type, data_file_type;
# Default type for anything under /cache
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
+
/dev/cam u:object_r:camera_device:s0
/dev/console u:object_r:console_device:s0
/dev/cpuctl(/.*)? u:object_r:cpuctl_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
+# 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
+
#############################
# 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
+
#############################
# Cache files
#
@@ -128,3 +153,4 @@
# sysfs files
#
/sys/qemu_trace/process_name -- u:object_r:sysfs_writable:s0
+/sys/devices/platform/nfc-power/nfc_power -- u:object_r:sysfs_nfc_power_writable:s0
diff --git a/nfc.te b/nfc.te
index b20d236..7ff3c01 100644
--- a/nfc.te
+++ b/nfc.te
@@ -4,6 +4,7 @@ app_domain(nfc)
# NFC device access.
allow nfc nfc_device:chr_file rw_file_perms;
+allow nfc nfc_ctrl_device:chr_file rw_file_perms;
# Data file accesses.
allow nfc nfc_data_file:dir create_dir_perms;
diff --git a/radio.te b/radio.te
index 9094cce..94cf54b 100644
--- a/radio.te
+++ b/radio.te
@@ -13,5 +13,6 @@ unix_socket_connect(radio, rild, rild)
# Data file accesses.
allow radio radio_data_file:dir create_dir_perms;
allow radio radio_data_file:notdevfile_class_set create_file_perms;
-
+allow radio radio_telephony_data_file:dir r_dir_perms;
+allow radio radio_telephony_data_file:file create_file_perms;
allow radio alarm_device:chr_file rw_file_perms;
diff --git a/rild.te b/rild.te
index 2857892..b14bd10 100644
--- a/rild.te
+++ b/rild.te
@@ -7,6 +7,7 @@ net_domain(rild)
allow rild kernel:system module_request;
unix_socket_connect(rild, property, init)
unix_socket_connect(rild, qemud, qemud)
+allow rild self:netlink_route_socket { setopt };
allow rild self:capability { setuid net_admin net_raw };
allow rild alarm_device:chr_file rw_file_perms;
allow rild cgroup:dir create_dir_perms;
@@ -19,3 +20,9 @@ allow rild shell_exec:file rx_file_perms;
dontaudit rild self:capability sys_admin;
# XXX Label sysfs files with a specific type?
allow rild sysfs:file rw_file_perms;
+allow rild radio_telephony_data_file:file rw_file_perms;
+allow rild radio_telephony_data_file:dir r_dir_perms;
+allow rild radio_nv_data_file:file rw_file_perms;
+allow rild radio_nv_data_file:dir r_dir_perms;
+allow rild efs_radio_nv_data_file:file rw_file_perms;
+
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
--
1.7.5.4
Bryan Hinton
On Fri, Mar 2, 2012 at 10:03 AM, Subramani Venkatesh
<selinuxv31@gmail.com> wrote:
> Thanks Stephen,
> I did not add Bryan changes, i will add them now and see the difference.
> Thanks for debug information.
>
> Regards,
> Subbu
>
> On Fri, Mar 2, 2012 at 10:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Fri, 2012-03-02 at 10:29 -0500, Subramani Venkatesh wrote:
>>> Hi,
>>> I got SE Android working on Galaxy Nexus, followed instructions from
>>> http://selinuxproject.org/page/SEAndroid
>>> After executing "setenforce 1", launching applications works as
>>> expected, but it is only short period of time, later it reboots. Would
>>> like to debug the issues, Is their any guide to debug SE on Android?
>>
>> Did you try the policy changes posted by Bryan Hinton for the Galaxy
>> Nexus? See:
>> http://marc.info/?l=selinux&m=132752617008734&w=2
>>
>> Before running setenforce 1, you should check for any avc messages in
>> your dmesg output, e.g.
>> adb shell dmesg | grep avc
>>
>> Such denials need to be addressed through policy changes or labeling
>> changes before you go to enforcing mode.
>>
>> You might want to start a process capturing dmesg output just before you
>> go to enforcing mode, e.g.
>> adb shell su 0 cat /proc/kmsg
>>
>> adb logcat *:E can also be helpful.
>>
>> --
>> 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 17:51 ` Bryan Hinton
@ 2012-03-02 19:31 ` Stephen Smalley
2012-03-02 22:13 ` Bryan Hinton
2012-03-02 20:26 ` Stephen Smalley
1 sibling, 1 reply; 14+ messages in thread
From: Stephen Smalley @ 2012-03-02 19:31 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Subramani Venkatesh, selinux
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 17:51 ` Bryan Hinton
2012-03-02 19:31 ` Stephen Smalley
@ 2012-03-02 20:26 ` Stephen Smalley
2012-03-02 22:16 ` Bryan Hinton
1 sibling, 1 reply; 14+ messages in thread
From: Stephen Smalley @ 2012-03-02 20:26 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Subramani Venkatesh, selinux
On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote:
> Here is the latest policy that I am using.
BTW, I think we will ultimately need some per-device policy files that
get merged into the policy, much as there are per-device
ueventd.<board>.rc and init.<board>.rc files. At least for
file_contexts, and possibly for policy rules as well.
--
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 19:31 ` Stephen Smalley
@ 2012-03-02 22:13 ` Bryan Hinton
2012-03-06 19:16 ` Stephen Smalley
0 siblings, 1 reply; 14+ messages in thread
From: Bryan Hinton @ 2012-03-02 22:13 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Subramani Venkatesh, selinux
Thank you for the feedback. An updated patch for inclusion into the
sepolicy tree, is below.
My replies to your comments are below the patch.
From: Bryan Hinton <bryan@bryanhinton.com>
Date: Fri, 2 Mar 2012 15:45:06 -0600
Subject: [PATCH] Updated policy for SCH-i515. These changes placed
into the public domain.
Change-Id: Ie8776fd6ed6e84c40f545091358d2508e31bd02b
---
domain.te | 2 ++
file.te | 1 +
file_contexts | 12 +++++++++++-
rild.te | 1 +
4 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/domain.te b/domain.te
index 55c9ecd..cd7f938 100644
--- a/domain.te
+++ b/domain.te
@@ -86,6 +86,8 @@ 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;
+
# Read access to pseudo filesystems.
r_dir_file(domain, proc)
r_dir_file(domain, sysfs)
diff --git a/file.te b/file.te
index 11c3ef6..a530f2c 100644
--- a/file.te
+++ b/file.te
@@ -43,6 +43,7 @@ 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 sysfs_nfc_power_writable, fs_type, sysfs_type, mlstrustedobject;
# /data/data subdirectories - app sandboxes
type app_data_file, file_type, data_file_type;
# Default type for anything under /cache
diff --git a/file_contexts b/file_contexts
index 92c6bb0..b249004 100644
--- a/file_contexts
+++ b/file_contexts
@@ -19,6 +19,8 @@
/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
+/dev/cdma_.* u:object_r:radio_device:s0
+/dev/lte_.* u:object_r:radio_device:s0
/dev/cam u:object_r:camera_device:s0
/dev/console u:object_r:console_device:s0
/dev/cpuctl(/.*)? u:object_r:cpuctl_device:s0
@@ -35,6 +37,7 @@
/dev/mtd/mtd5ro u:object_r:radio_device:s0
/dev/mtp_usb u:object_r:mtp_device:s0
/dev/pn544 u:object_r:nfc_device:s0
+/dev/ttyO3 u:object_r:nfc_device:s0
/dev/ptmx u:object_r:ptmx_device:s0
/dev/pvrsrvkm u:object_r:powervr_device:s0
/dev/qemu_.* u:object_r:qemu_device:s0
@@ -66,7 +69,8 @@
/dev/socket/zygote u:object_r:zygote_socket:s0
/dev/spdif_out.* u:object_r:audio_device:s0
/dev/tegra.* u:object_r:video_device:s0
-/dev/tty[0-9]* u:object_r:tty_device:s0
+/dev/tty[0-2]* u:object_r:tty_device:s0
+/dev/tty[4-9]* u:object_r:tty_device:s0
/dev/ttyS[0-9]* u:object_r:serial_device:s0
/dev/uinput u:object_r:input_device:s0
/dev/urandom u:object_r:urandom_device:s0
@@ -116,10 +120,15 @@
/data/misc/wifi(/.*)? u:object_r:wifi_data_file:s0
# App sandboxes
/data/data/.* u:object_r:app_data_file:s0
+/data/data/com.android.providers.telephony/databases(/.*)?
u:object_r:radio_data_file:s0
+/data/data/com.android.providers.telephony/(optable\.db)?
u:object_r:radio_data_file:s0
+
#############################
# efs files
#
/efs(/.*)? u:object_r:efs_file:s0
+/data/radio/nv_data.bin.* u:object_r:radio_data_file:s0
+/factory/nv_data.bin.* u:object_r:radio_data_file:s0
#############################
# Cache files
#
@@ -128,3 +137,4 @@
# sysfs files
#
/sys/qemu_trace/process_name -- u:object_r:sysfs_writable:s0
+/sys/devices/platform/nfc-power/nfc_power --
u:object_r:sysfs_nfc_power_writable:s0
diff --git a/rild.te b/rild.te
index 2857892..9201d43 100644
--- a/rild.te
+++ b/rild.te
@@ -7,6 +7,7 @@ net_domain(rild)
allow rild kernel:system module_request;
unix_socket_connect(rild, property, init)
unix_socket_connect(rild, qemud, qemud)
+allow rild self:netlink_route_socket { setopt };
allow rild self:capability { setuid net_admin net_raw };
allow rild alarm_device:chr_file rw_file_perms;
allow rild cgroup:dir create_dir_perms;
--
On Fri, Mar 2, 2012 at 1:31 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 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.
>>>Understood. I removed the nfc_ctrl_device type and reused nfc_device for /dev/ttyO3.
>
>> 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.
>>>I'm also thinking that all domains should not have access.
>>>This domain is only used for the label on this file /sys/devices/platform/nfc-power/nfc_power as follows:
>>>u:object_r:sysfs_nfc_power_writable:s0
>>>I think this could use some improvement in terms of increased granularity. ...I'm thinking about how to go about it.
>
>> 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;
>
>>> Per above item.
>
>> @@ -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?
>>>I removed both and reused radio_data_file.
>
>> 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
>>>Done.
>
>> @@ -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.
>>>Fixed per above item.
>
>> +# 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?
>>>I removed both and reused radio_data_file.
>
>> 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.
>>>Removed additional types per above comment, and reused radio_data_file.
Bryan Hinton
>
> --
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 20:26 ` Stephen Smalley
@ 2012-03-02 22:16 ` Bryan Hinton
2012-03-02 23:02 ` Subramani Venkatesh
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Bryan Hinton @ 2012-03-02 22:16 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Subramani Venkatesh, selinux
I agree. A per-device file_contexts file makes sense given the
variation in radio types between ICS based devices.
On Fri, Mar 2, 2012 at 2:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote:
>> Here is the latest policy that I am using.
>
> BTW, I think we will ultimately need some per-device policy files that
> get merged into the policy, much as there are per-device
> ueventd.<board>.rc and init.<board>.rc files. At least for
> file_contexts, and possibly for policy rules as well.
>
> --
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 22:16 ` Bryan Hinton
@ 2012-03-02 23:02 ` Subramani Venkatesh
2012-03-06 2:42 ` Subramani Venkatesh
2012-03-06 19:01 ` Stephen Smalley
2 siblings, 0 replies; 14+ messages in thread
From: Subramani Venkatesh @ 2012-03-02 23:02 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Stephen Smalley, selinux
Yes per device file_contexts makes easy, I have GSM modem, so I had to
label files according to my device. and also Define policy rukes.
Changes will be emailed soon.
Regards,
Subbu
On Fri, Mar 2, 2012 at 5:16 PM, Bryan Hinton <bryan@bryanhinton.com> wrote:
> I agree. A per-device file_contexts file makes sense given the
> variation in radio types between ICS based devices.
>
> On Fri, Mar 2, 2012 at 2:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote:
>>> Here is the latest policy that I am using.
>>
>> BTW, I think we will ultimately need some per-device policy files that
>> get merged into the policy, much as there are per-device
>> ueventd.<board>.rc and init.<board>.rc files. At least for
>> file_contexts, and possibly for policy rules as well.
>>
>> --
>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 22:16 ` Bryan Hinton
2012-03-02 23:02 ` Subramani Venkatesh
@ 2012-03-06 2:42 ` Subramani Venkatesh
2012-03-06 16:18 ` Bryan Hinton
2012-03-06 19:01 ` Stephen Smalley
2 siblings, 1 reply; 14+ messages in thread
From: Subramani Venkatesh @ 2012-03-06 2:42 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Stephen Smalley, selinux
Hi Bryan,
Thanks for the patch you posted earlier, I tried adding your changes,
some changes works, some did not take effect for example
"+/factory/nv_data.bin.* u:object_r:radio_data_file:s0", I
am seeing /factory directory as unlabeled, not sure what I am missing,
do we need to do any change to init.rc file?
Regards,
Subbu
On Fri, Mar 2, 2012 at 5:16 PM, Bryan Hinton <bryan@bryanhinton.com> wrote:
> I agree. A per-device file_contexts file makes sense given the
> variation in radio types between ICS based devices.
>
> On Fri, Mar 2, 2012 at 2:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote:
>>> Here is the latest policy that I am using.
>>
>> BTW, I think we will ultimately need some per-device policy files that
>> get merged into the policy, much as there are per-device
>> ueventd.<board>.rc and init.<board>.rc files. At least for
>> file_contexts, and possibly for policy rules as well.
>>
>> --
>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-06 2:42 ` Subramani Venkatesh
@ 2012-03-06 16:18 ` Bryan Hinton
0 siblings, 0 replies; 14+ messages in thread
From: Bryan Hinton @ 2012-03-06 16:18 UTC (permalink / raw)
To: selinux
Yes, you are correct. That mount point needs a label and the security
context should be set.
Bryan Hinton
On Mon, Mar 5, 2012 at 8:42 PM, Subramani Venkatesh
<selinuxv31@gmail.com> wrote:
> Hi Bryan,
> Thanks for the patch you posted earlier, I tried adding your changes,
> some changes works, some did not take effect for example
> "+/factory/nv_data.bin.* u:object_r:radio_data_file:s0", I
> am seeing /factory directory as unlabeled, not sure what I am missing,
> do we need to do any change to init.rc file?
>
> Regards,
> Subbu
>
>
>
>
>
> On Fri, Mar 2, 2012 at 5:16 PM, Bryan Hinton <bryan@bryanhinton.com> wrote:
>> I agree. A per-device file_contexts file makes sense given the
>> variation in radio types between ICS based devices.
>>
>> On Fri, Mar 2, 2012 at 2:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> On Fri, 2012-03-02 at 11:51 -0600, Bryan Hinton wrote:
>>>> Here is the latest policy that I am using.
>>>
>>> BTW, I think we will ultimately need some per-device policy files that
>>> get merged into the policy, much as there are per-device
>>> ueventd.<board>.rc and init.<board>.rc files. At least for
>>> file_contexts, and possibly for policy rules as well.
>>>
>>> --
>>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 22:16 ` Bryan Hinton
2012-03-02 23:02 ` Subramani Venkatesh
2012-03-06 2:42 ` Subramani Venkatesh
@ 2012-03-06 19:01 ` Stephen Smalley
2 siblings, 0 replies; 14+ messages in thread
From: Stephen Smalley @ 2012-03-06 19:01 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Subramani Venkatesh, selinux
On Fri, 2012-03-02 at 16:16 -0600, Bryan Hinton wrote:
> I agree. A per-device file_contexts file makes sense given the
> variation in radio types between ICS based devices.
Support for per-device .te and .fc files has been added to the sepolicy
Android.mk file. Thus, you can place your device-specific additions for
file_contexts in a sepolicy.fc file or for policy rules in a sepolicy.te
file under target/board/<device>, device/<vendor>/<device>, or
vendor/<vendor>/<device> and have it automatically included into the
policy.
Since the device-specific .fc files are appended to the end of
file_contexts, they will take precedence over less specific entries in
the base file_contexts file (e.g. no need to change the /dev/tty[0-9]
entry in file_contexts in order to override the context for /dev/tty03;
you can just add the latter to your .fc file and it should take
precedence). The device-specific .te files are likewise appended after
the base set of .te files, although order there shouldn't matter.
This is still experimental and may change further. For example, if we
wanted to support multiple .fc or .te files per device, we might
introduce an optional sepolicy subdirectory under the device directories
that could contain any number of such files.
These changes are available in our sepolicy tree, but not yet in the
AOSP one. In order to ensure that you use our sepolicy tree, you may
need to update your local_manifest.xml file. I have placed updated
local_manifest.xml (for git-based access) and local_manifest_http.xml
(for http-based access) files under
http://selinuxproject.org/~seandroid/
--
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-02 22:13 ` Bryan Hinton
@ 2012-03-06 19:16 ` Stephen Smalley
2012-03-06 19:26 ` Bryan Hinton
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Smalley @ 2012-03-06 19:16 UTC (permalink / raw)
To: Bryan Hinton; +Cc: Subramani Venkatesh, selinux
On Fri, 2012-03-02 at 16:13 -0600, Bryan Hinton wrote:
> Thank you for the feedback. An updated patch for inclusion into the
> sepolicy tree, is below.
> My replies to your comments are below the patch.
Thanks, a few comments below.
> @@ -35,6 +37,7 @@
> /dev/mtd/mtd5ro u:object_r:radio_device:s0
> /dev/mtp_usb u:object_r:mtp_device:s0
> /dev/pn544 u:object_r:nfc_device:s0
> +/dev/ttyO3 u:object_r:nfc_device:s0
I suspect this one should go into a separate sepolicy.fc file for the
device, now that we have support for such files.
> @@ -66,7 +69,8 @@
> /dev/socket/zygote u:object_r:zygote_socket:s0
> /dev/spdif_out.* u:object_r:audio_device:s0
> /dev/tegra.* u:object_r:video_device:s0
> -/dev/tty[0-9]* u:object_r:tty_device:s0
> +/dev/tty[0-2]* u:object_r:tty_device:s0
> +/dev/tty[4-9]* u:object_r:tty_device:s0
Not necessary; a fully specified (no regex) pathname will always take
precedence over a regex, and a later entry will take precedence over an
earlier one. So it should suffice to have the /dev/tty03 in your
sepolicy.fc file for the device.
> @@ -116,10 +120,15 @@
> /data/misc/wifi(/.*)? u:object_r:wifi_data_file:s0
> # App sandboxes
> /data/data/.* u:object_r:app_data_file:s0
> +/data/data/com.android.providers.telephony/databases(/.*)?
> u:object_r:radio_data_file:s0
> +/data/data/com.android.providers.telephony/(optable\.db)?
> u:object_r:radio_data_file:s0
The last pathname regex doesn't seem right. If you just want
optable.db, then drop the parens and ?; if you want everything under the
directory, then you can just use (/.*)?.
Also, your patch was line wrapped and thus can't be applied.
Make sure you use preformat or equivalent in your mail client or
directly send via git send-email.
> +
> #############################
> # efs files
> #
> /efs(/.*)? u:object_r:efs_file:s0
> +/data/radio/nv_data.bin.* u:object_r:radio_data_file:s0
> +/factory/nv_data.bin.* u:object_r:radio_data_file:s0
I suspect these will go into your sepolicy.fc file for the device.
--
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SE Android on Galaxy Nexus
2012-03-06 19:16 ` Stephen Smalley
@ 2012-03-06 19:26 ` Bryan Hinton
0 siblings, 0 replies; 14+ messages in thread
From: Bryan Hinton @ 2012-03-06 19:26 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Subramani Venkatesh, selinux
Thanks. I'll make the necessary changes. I've also made a few other
small policy changes for the tuna/toro device. I'll get all of that
cleaned up and resend a bit later.
On Tue, Mar 6, 2012 at 1:16 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2012-03-02 at 16:13 -0600, Bryan Hinton wrote:
>> Thank you for the feedback. An updated patch for inclusion into the
>> sepolicy tree, is below.
>> My replies to your comments are below the patch.
>
> Thanks, a few comments below.
>
>> @@ -35,6 +37,7 @@
>> /dev/mtd/mtd5ro u:object_r:radio_device:s0
>> /dev/mtp_usb u:object_r:mtp_device:s0
>> /dev/pn544 u:object_r:nfc_device:s0
>> +/dev/ttyO3 u:object_r:nfc_device:s0
>
> I suspect this one should go into a separate sepolicy.fc file for the
> device, now that we have support for such files.
>
>> @@ -66,7 +69,8 @@
>> /dev/socket/zygote u:object_r:zygote_socket:s0
>> /dev/spdif_out.* u:object_r:audio_device:s0
>> /dev/tegra.* u:object_r:video_device:s0
>> -/dev/tty[0-9]* u:object_r:tty_device:s0
>> +/dev/tty[0-2]* u:object_r:tty_device:s0
>> +/dev/tty[4-9]* u:object_r:tty_device:s0
>
> Not necessary; a fully specified (no regex) pathname will always take
> precedence over a regex, and a later entry will take precedence over an
> earlier one. So it should suffice to have the /dev/tty03 in your
> sepolicy.fc file for the device.
>
>> @@ -116,10 +120,15 @@
>> /data/misc/wifi(/.*)? u:object_r:wifi_data_file:s0
>> # App sandboxes
>> /data/data/.* u:object_r:app_data_file:s0
>> +/data/data/com.android.providers.telephony/databases(/.*)?
>> u:object_r:radio_data_file:s0
>> +/data/data/com.android.providers.telephony/(optable\.db)?
>> u:object_r:radio_data_file:s0
>
> The last pathname regex doesn't seem right. If you just want
> optable.db, then drop the parens and ?; if you want everything under the
> directory, then you can just use (/.*)?.
>
> Also, your patch was line wrapped and thus can't be applied.
> Make sure you use preformat or equivalent in your mail client or
> directly send via git send-email.
>
>> +
>> #############################
>> # efs files
>> #
>> /efs(/.*)? u:object_r:efs_file:s0
>> +/data/radio/nv_data.bin.* u:object_r:radio_data_file:s0
>> +/factory/nv_data.bin.* u:object_r:radio_data_file:s0
>
> I suspect these will go into your sepolicy.fc file for the device.
>
> --
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-03-06 19:26 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-02 15:29 SE Android on Galaxy Nexus Subramani Venkatesh
2012-03-02 15:39 ` Stephen Smalley
2012-03-02 16:03 ` Subramani Venkatesh
2012-03-02 17:51 ` Bryan Hinton
2012-03-02 19:31 ` Stephen Smalley
2012-03-02 22:13 ` Bryan Hinton
2012-03-06 19:16 ` Stephen Smalley
2012-03-06 19:26 ` Bryan Hinton
2012-03-02 20:26 ` Stephen Smalley
2012-03-02 22:16 ` Bryan Hinton
2012-03-02 23:02 ` Subramani Venkatesh
2012-03-06 2:42 ` Subramani Venkatesh
2012-03-06 16:18 ` Bryan Hinton
2012-03-06 19:01 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.