Vold needs to be able to query if the directory exists and
eventually to fix permissions and the owner.
Typical error:
W vold : type=1400 audit(0.0:485): avc: denied { getattr }
for path="/data/misc/profiles/cur/11/foreign-dex" dev="dm-2"
ino=343857 scontext=u:r:vold:s0
tcontext=u:object_r:user_profile_foreign_dex_data_file:s0 tclass=dir
permissive=0
Bug: 27517932
Change-Id: Iff10c864634baa97cc814916ee7495b262e0c7eb
Motivation: Domain is overly permissive. Start removing permissions
from domain and assign them to the domain_deprecated attribute.
Domain_deprecated and domain can initially be assigned to all
domains. The goal is to not assign domain_deprecated to new domains
and to start removing domain_deprecated where it is not required or
reassigning the appropriate permissions to the inheriting domain
when necessary.
Bug: 25433265
Change-Id: I8b11cb137df7bdd382629c98d916a73fe276413c
vold hasn't use the generic "block_device" label since
commit 273d7ea4ca (Sept 2014), and
the auditallow statement in vold hasn't triggered since that time.
Remove the rule which allows vold access to the generic block_device
label, and remove the vold exception.
Thanks to jorgelo for reminding me about this.
Change-Id: Idd6cdc20f5be9a40c5c8f6d43bbf902a475ba1c9
When the toolbox domain was introduced, we allowed all domains to exec it
to avoid breakage. However, only domains that were previously allowed the
ability to exec /system files would have been able to do this prior to the
introduction of the toolbox domain. Remove the rule from domain.te and add
rules to all domains that are already allowed execute_no_trans to system_file.
Requires coordination with device-specific policy changes with the same Change-Id.
Change-Id: Ie46209f0412f9914857dc3d7c6b0917b7031aae5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
avc: denied { sys_chroot } for capability=18 scontext=u:r:vold:s0 tcontext=u:r:vold:s0 tclass=capability permissive=1
avc: denied { mounton } for path="/storage" dev="tmpfs" ino=4155 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir permissive=1
avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=filesystem permissive=0
Bug: 21858077
Change-Id: Ie481d190c5e7a774fbf80fee6e39a980f382967e
Allow vold, healthd, slideshow, and watchdogd access to /dev/kmsg.
These processes log to the kernel dmesg ring buffer, so they need
write access to that file.
Addresses the following denials:
avc: denied { write } for pid=134 comm="watchdogd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:watchdogd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=166 comm="healthd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:healthd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=180 comm="vold" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:vold:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
These denials were triggered by the change in
https://android-review.googlesource.com/151209 . Prior to that change,
any code which called klog_init would (unnecessarily) create the
device node themselves, rather than using the already existing device
node.
Drop special /dev/__null__ handling from watchdogd. As of
https://android-review.googlesource.com/148288 , watchdogd no longer
creates it's own /dev/null device, so it's unnecessary for us
to allow for it.
Drop mknod from healthd, slideshow, and watchdogd. healthd and slideshow
only needed mknod to create /dev/__kmsg__, which is now obsolete.
watchdogd only needed mknod to create /dev/__kmsg__ and /dev/__null__,
which again is now obsolete.
(cherry picked from e2651972c1)
Bug: 21242418
Change-Id: If01c8001084575e7441253f0fa8b4179ae33f534
This new property is used as a control verb for running a recursive
restorecon at the path contained in the property value.
Defines a new label and grants access to vold, which invokes it when
mounting private adopted volumes.
Bug: 21121357
Change-Id: I8ff12a146e54a505aa5b43a542578891563d647a
Allow vold, healthd, slideshow, and watchdogd access to /dev/kmsg.
These processes log to the kernel dmesg ring buffer, so they need
write access to that file.
Addresses the following denials:
avc: denied { write } for pid=134 comm="watchdogd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:watchdogd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=166 comm="healthd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:healthd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=180 comm="vold" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:vold:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
These denials were triggered by the change in
https://android-review.googlesource.com/151209 . Prior to that change,
any code which called klog_init would (unnecessarily) create the
device node themselves, rather than using the already existing device
node.
Drop special /dev/__null__ handling from watchdogd. As of
https://android-review.googlesource.com/148288 , watchdogd no longer
creates it's own /dev/null device, so it's unnecessary for us
to allow for it.
Drop mknod from healthd, slideshow, and watchdogd. healthd and slideshow
only needed mknod to create /dev/__kmsg__, which is now obsolete.
watchdogd only needed mknod to create /dev/__kmsg__ and /dev/__null__,
which again is now obsolete.
Bug: 21242418
Change-Id: If01c8001084575e7441253f0fa8b4179ae33f534
Define an explicit label for /proc/sys/vm/drop_caches and grant to
the various people who need it, including vold which uses it when
performing storage benchmarks.
Also let vold create new directories under it's private storage area
where the benchmarks will be carried out. Mirror the definition of
the private storage area on expanded media.
avc: denied { write } for name="drop_caches" dev="proc" ino=20524 scontext=u:r:vold:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=0
Bug: 21172095
Change-Id: I300b1cdbd235ff60e64064d3ba6e5ea783baf23f
A common source of mistakes when authoring sepolicy is properly
setting up property sets. This is a 3 part step of:
1. Allowing the unix domain connection to the init/property service
2. Allowing write on the property_socket file
3. Allowing the set on class property_service
The macro unix_socket_connect() handled 1 and 2, but could be
confusing for first time policy authors. 3 had to be explicitly
added.
To correct this, we introduce a new macros:
set_prop(sourcedomain, targetprop)
This macro handles steps 1, 2 and 3.
No difference in sediff is expected.
(cherrypicked from commit 625a3526f1)
Change-Id: I630ba0178439c935d08062892990d43a3cc1239e
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
A common source of mistakes when authoring sepolicy is properly
setting up property sets. This is a 3 part step of:
1. Allowing the unix domain connection to the init/property service
2. Allowing write on the property_socket file
3. Allowing the set on class property_service
The macro unix_socket_connect() handled 1 and 2, but could be
confusing for first time policy authors. 3 had to be explicitly
added.
To correct this, we introduce a new macros:
set_prop(sourcedomain, targetprop)
This macro handles steps 1, 2 and 3.
No difference in sediff is expected.
Change-Id: I630ba0178439c935d08062892990d43a3cc1239e
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
This enables an optimization of bypassing the FUSE overhead when
migrating emulated storage between volumes.
avc: denied { write } for path="/mnt/expand/6cba9b95-4fc8-4096-b51f-bdb2c007d059/media/obb/.nomedia" dev="dm-0" ino=387843 scontext=u:r:vold:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=file permissive=1
Bug: 19993667
Change-Id: I2bb9aaca50ed988ded6afec6d7fbe190903707e0
vold works with two broad classes of block devices: untrusted devices
that come in from the wild, and trusted devices.
When running blkid and fsck, we pick which SELinux execution domain
to use based on which class the device belongs to.
Bug: 19993667
Change-Id: I44f5bac5dd94f0f76f3e4ef50ddbde5a32bd17a5
Creates new directory at /data/misc/vold for storing key material
on internal storage. Only vold should have access to this label.
Change-Id: I7f2d1314ad3b2686e29e2037207ad83d2d3bf465
Create new vold_fsck domain that only has access to vold_block
devices to prevent any access to internal userdata.
Change-Id: I25ddcd16cbf83d7a25b70bc64d95f5345d0d5731
Assign a more specific type than block_device to all
block devices created or accessed by vold. Allow vold
to set the context on the device nodes it creates.
vold can create extra loop devices (/dev/block/loopN) and
block devices for volumes it manages (/dev/block/vold/M:N).
vold can read/write device mapper block devices (/dev/block/dm-N)
created for encrypted volumes.
vold can read/write metadata partitions used to store encryption metadata.
The metadata_block_device type should be assigned in device-specific
policy to the partition specified by the encryptable= mount option
for the userata entry in the fstab.<board> file.
This change does not remove the ability to create or read/write
generic block_device devices by vold, so it should not break anything.
It does add an auditallow statement on such accesses so that we can track
remaining cases where we need to label such device nodes so that we can
ultimately remove this access.
Change-Id: Id3bea28f5958086716cd3db055bea309b3b5fa5a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow error reporting via the pty supplied by init.
Allow vold to invoke fsck for checking volumes.
Addresses denials such as:
avc: denied { ioctl } for pid=133 comm="e2fsck" path="/dev/pts/0" dev="devpts" ino=3 scontext=u:r:fsck:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file
avc: denied { execute } for pid=201 comm="vold" name="e2fsck" dev="mmcblk0p25" ino=98 scontext=u:r:vold:s0 tcontext=u:object_r:fsck_exec:s0 tclass=file
These denials show up if you have encrypted userdata.
Change-Id: Idc8e6f83a0751f17cde0ee5e4b1fbd6efe164e4c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Introduce separate types for the userdata and cache block
devices so that we can assign them and allow access to them
in device-specific policy without allowing access to any other
block device (e.g. system). These types will only be used if
assigned to device node paths in the device-specific file_contexts
configuration. Otherwise, this change will have no impact - the
userdata and cache block devices will continue to default to block_device
type.
To avoid breakage when these new types are assigned to the userdata
block device, allow access by vold and uncrypt, but auditallow
these accesses to confirm that these are required.
Change-Id: I99d24f06506f51ebf1d186d9c393b3cad60e98d7
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The bugs that motivated bringing back the unlabeled allowall rules,
https://android-review.googlesource.com/#/c/94971/
should be resolved by the following changes:
https://android-review.googlesource.com/#/c/94966/https://android-review.googlesource.com/#/c/96080/
Beyond those changes, installd needs to be able to remove package directories
for apps that no longer exist or have moved (e.g. to priv-app) on upgrades, so
allow it the permissions required for this purpose. vold needs to be able
to chown/chmod/restorecon files in asec containers so allow it the
permissions to do so. system_server tries to access all /data/data
subdirectories so permit it to do so. installd and system_server
read the pkg.apk file before it has been relabeled by vold and therefore
need to read unlabeled files.
Change-Id: I70da7d605c0d037eaa5f3f5fda24f5e7715451dc
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Introduce wakelock_use(). This macro declares that a domain uses
wakelocks.
Wakelocks require both read-write access to files in /sys/power, and
CAP_BLOCK_SUSPEND. This macro helps ensure that both capabilities and
file access are granted at the same time.
Still TODO: fix device specific wakelock use.
Change-Id: Ib98ff374a73f89e403acd9f5e024988f59f08115
This was originally to limit the ability to relabel files to
particular types given the ability of all domains to relabelfrom
unlabeled files. Since the latter was removed by
Ied84f8b4b1a0896c1b9f7d783b7463ce09d4807b, this no longer serves
any purpose.
Change-Id: Ic41e94437188183f15ed8b3732c6cd5918da3397
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The ctl_default_prop label is a bit too generic for some
of the priveleged domains when describing access rights.
Instead, be explicit about which services are being started
and stopped by introducing new ctl property keys.
Change-Id: I1d0c6f6b3e8bd63da30bd6c7b084da44f063246a
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Replace * or any permission set containing create with
create_socket_perms or create_stream_socket_perms.
Add net_domain() to all domains using network sockets and
delete rules already covered by domain.te or net.te.
For netlink_route_socket, only nlmsg_write needs to be separately
granted to specific domains that are permitted to modify the routing
table. Clarification: read/write permissions are just ability to
perform read/recv() or write/send() on the socket, whereas nlmsg_read/
nlmsg_write permissions control ability to observe or modify the
underlying kernel state accessed via the socket.
See security/selinux/nlmsgtab.c in the kernel for the mapping of
netlink message types to nlmsg_read or nlmsg_write.
Delete legacy rule for b/12061011.
This change does not touch any rules where only read/write were allowed
to a socket created by another domain (inherited across exec or
received across socket or binder IPC). We may wish to rewrite some or all
of those rules with the rw_socket_perms macro but that is a separate
change.
Change-Id: Ib0637ab86f6d388043eff928e5d96beb02e5450e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This new type will allow us to write finer-grained
policy concerning asec containers. Some files of
these containers need to be world readable.
Change-Id: Iefee74214d664acd262edecbb4f981d633ff96ce
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
