mirror of
https://github.com/hardkernel/linux.git
synced 2026-06-06 10:58:48 +09:00
8c288004aa
Add a flag option to get xattr method that could have a bit flag of XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then set in the __vfs_getxattr path when called by security infrastructure. This handles the case of a union filesystem driver that is being requested by the security layer to report back the xattr data. For the use case where access is to be blocked by the security layer. The path then could be security(dentry) -> __vfs_getxattr(dentry...XATTR_NOSECURITY) -> handler->get(dentry...XATTR_NOSECURITY) -> __vfs_getxattr(lower_dentry...XATTR_NOSECURITY) -> lower_handler->get(lower_dentry...XATTR_NOSECURITY) which would report back through the chain data and success as expected, the logging security layer at the top would have the data to determine the access permissions and report back the target context that was blocked. Without the get handler flag, the path on a union filesystem would be the errant security(dentry) -> __vfs_getxattr(dentry) -> handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested -> security(lower_dentry, log off) -> lower_handler->get(lower_dentry) which would report back through the chain no data, and -EACCES. For selinux for both cases, this would translate to a correctly determined blocked access. In the first case with this change a correct avc log would be reported, in the second legacy case an incorrect avc log would be reported against an uninitialized u:object_r:unlabeled:s0 context making the logs cosmetically useless for audit2allow. This patch series is inert and is the wide-spread addition of the flags option for xattr functions, and a replacement of __vfs_getxattr with __vfs_getxattr(...XATTR_NOSECURITY). Bug: 204981027 Link: https://lore.kernel.org/lkml/20211117015806.2192263-2-dvander@google.com Change-Id: Id2c6fa6eeb2b5cca5a11e0cd02a3fbf2a5fcbef4 Signed-off-by: David Anderson <dvander@google.com> Signed-off-by: Mark Salyzyn <salyzyn@android.com>