Something went wrong on our end
-
Nick Kralevich authored
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
Nick Kralevich authoredModify 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
global_macros 2.52 KiB