GitLab

App data directories are labeled by installd at creation time
based on package information, seapp_contexts, and file_contexts.
Prior to this change, restorecon and restorecon_recursive did not
know how to label app data directories and would merely label
them based on file_contexts, causing them to be (mis)labeled with
a single security context if restorecon was applied to /data/data/<pkgname>
or /data/user/N/<pkgname>.  Extend restorecon to correctly handle app data
directories based on all of the relevant information.

After applying this change and its dependencies (including rewriting
toolbox restorecon to use libselinux), a restorecon -Rv /data/data
only relabels the lib symlinks in the app data directories, which I
believe is harmless and arguably is a bug in installd.  Originally
when the lib subdirectories were created in each app data directory
we labeled them with system_data_file to distinguish them from
app data, prevent direct writes by apps, and allow execute by apps.
However, when the lib directories were moved under /data/app-lib and only the
symlink was left behind, it continued to be labeled system_data_file
as a side effect of the fact that it is created before installd
calls selinux_android_setfilecon2() on the package directory and
thus inherits the original parent directory security context.  Offhand,
I don't see a real reason to not just label the symlinks with the app data
directory context even though the symlinks do have a different UID (install)
since the containing directory is owned by the app UID so apps
can already unlink and re-create the symlink at will.  So I think this
change by restorecon is harmless and we could switch installd to
applying the setfilecon2 first before creating the symlinks so that
they are originally labeled this way.

Change-Id: I698b1b2c3f00f31fbb2015edf23d33b51aa5bba1
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>