Don't grant hard link capabilities by default.

Modify create_file_perms and create_dir_perms so it doesn't have
the "link" permission. This permission controls whether hard links
are allowed or not on the given file label. Hard links are a common
source of security bugs, and isn't something we want to support by
default.

Get rid of link_file_perms and move the necessary permissions into
create_file_perms and create_dir_perms. Nobody is using this macro,
so it's pointless to keep it around.

Get rid of unlink on directories. It returns EISDIR if you attempt to
do it, independent of SELinux permissions.

SELinux domains which have a need for hard linking for a particular
file type can add it back to their permission set on an as-needed basis.

Add a compile time assertion (neverallow rule) for untrusted_app.
It's particularly dangerous for untrusted_app to ever have hard
link capabilities, and the neverallow rule will prevent regressions.

Bug: 19953790
Change-Id: I5e9493d2bf5da460d074f0bc5ad8ba7c14dec6e0

1 files changed, 8 insertions, 0 deletions

diff --git a/untrusted_app.te b/untrusted_app.te
index d88414c..f7ebdcb 100644
--- a/untrusted_app.te
+++ b/untrusted_app.te
@@ -176,3 +176,11 @@ neverallow untrusted_app property_type:property_service set;
 # never be granted to any other domain within mlstrustedsubject)
 # and untrusted_app is allowed fork permission to itself.
 neverallow untrusted_app mlstrustedsubject:process fork;
+
+# Do not allow untrusted_app to hard link to any files.
+# In particular, if untrusted_app links to other app data
+# files, installd will not be able to guarantee the deletion
+# of the linked to file. Hard links also contribute to security
+# bugs, so we want to ensure untrusted_app never has this
+# capability.
+neverallow untrusted_app file_type:file link;