(cherry picked from commit 15f5ee011a51e9e7574d1ecb1b82658281d294be)
Grant access to qualcomm camera daemon.
Bug: 28359909
Change-Id: I92520b4c9fe5d94a6c191f40963fec6b6ed1acb4
camera_device didn't really offer much in terms of control considering
that most domains that need camera_device, also need video_device and
vice versa.
Thus, drop camera_device from the policy.
Change-Id: Ib7773985ba3b93537702b113a2deb5d2f6f3c7ef
* Move binaries from /system/etc to /system/bin. That's the proper
place for binaries, and avoids having to preface each service entry
with /system/bin/sh
* Drop seclabel statements and rely on automatic domain transitions.
* remove call to init.qcom.class_main.sh , which doesn't exist.
This gets rid of the following unnecessary errors:
<3>[ 5.286834] init: Warning! Service qcom-c_main-sh needs a SELinux domain defined; please fix!
<5>[ 5.288970] type=1400 audit(1425327865.651:5): avc: denied { execute_no_trans } for pid=191 comm="init" path="/system/bin/sh" dev="mmcblk0p22" ino=341 scontext=u:r:init:s0 tcontext=u:object_r:shell_exec:s0 tclass=file
Fix some other minor policy issues.
Change-Id: Ib47d49b6c239ab7a2ebe6159465deb98b4b8cecb
This assigns the type defined by Id3bea28f5958086716cd3db055bea309b3b5fa5a
to the block device file for the metadata partition specified via the
encryptable= option for the userdata entry in the fstab.<board> file.
Change-Id: I0ef96fa716be89fa9f8b6c03014a76ac2556d06e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This assigns the types defined by Ie9c1f6d632f6e9e8cbba106f07f6b1979d2a3c4a
to the block device files for the system and recovery partitions
as per the fstab.<board> file.
Also rewrite the existing /dev/block entries for other partitions to
use the by-name symlinks where possible.
Change-Id: Ia1fbe871b567b5c4a7004b07c84d8d6348b81c47
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This assigns the types defined by I99d24f06506f51ebf1d186d9c393b3cad60e98d7
to the block device files for userdata and cache for this device.
Change-Id: I731ba250d694a080857e19ab996f4229bf003e30
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The ppd service which runs the mm-pp-daemon binary appears
to no longer be used. The last occurrence of the binary for
either flo or deb is with the jss15r and jls36i builds
respectively. In fact, current builds report that the ppd
service is explicitly being disabled.
<3>[ 5.023345] init: cannot find '/system/bin/mm-pp-daemon', disabling 'ppd'
Thus, just drop the selinux policy for it. While we're
at it, drop the ppd service entries from the init.flo.rc
file too.
Change-Id: I5902b6876d5bea33bb65dcaa505fc4ee13a61677
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Otherwise it is treated as a regex and matches any character.
Change-Id: Ic36c1329d446c03a38cb09745b03be28333d9a50
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
So that we do not relabel them on a restorecon -R /data.
Change-Id: Ibf51efcbe8fed395b214ee81c097c4b04d4ce335
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Bring policy over from the mako board which
has a lot of similar domains and services.
mako is also a Qualcomm board which allows
a lot of that policy to be directly brought
over and applied.
Included in this are some radio specific
pieces. Though not directly applicable to
flo, the deb board inherits this policy.
Change-Id: I6b294c7dc830189c08f1f981a239234a2c3f577f
Labeling nodes with appropriate types doesn't
introduce any new denials to the mix. This
list largely addresses the Qualcomm specific
nodes.
Various nodes are labeled with radio specific
types. Since the deb build inherits from this flo
policy, it is a good idea to include them.
Change-Id: Ia55a80af027c8bde933d45c41f4ed287f01adb2e
Don't run rmt in init's domain. /system/bin/rmt_storage
is a qualcomm specific daemon responsible for servicing modem
filesystem requests. It doesn't make sense to run rmt_storage
in init's domain, as doing so prevents us from fine tuning
its policy.
Keep the domain in permissive mode right now until we address
the following denials:
<5>[ 7.497467] type=1400 audit(1383939680.983:5): avc: denied { read write } for pid=193 comm="rmt_storage" name="mem" dev="tmpfs" ino=4010 scontext=u:r:rmt:s0 tcontext=u:object_r:kmem_device:s0 tclass=chr_file
<5>[ 7.497741] type=1400 audit(1383939680.983:6): avc: denied { open } for pid=193 comm="rmt_storage" name="mem" dev="tmpfs" ino=4010 scontext=u:r:rmt:s0 tcontext=u:object_r:kmem_device:s0 tclass=chr_file
We still need to get a better understanding of what rmt_storage
does and what rules should be applied to it.
Change-Id: I45d03fb93870f1b4bb64215f5dcd9a2a443f5566