FROMLIST: overlayfs: internal getxattr operations without sepolicy checking
Check impure, opaque, origin & meta xattr with no sepolicy audit (using __vfs_getxattr) since these operations are internal to overlayfs operations and do not disclose any data. This became an issue for credential override off since sys_admin would have been required by the caller; whereas would have been inherently present for the creator since it performed the mount. This is a change in operations since we do not check in the new ovl_do_vfs_getxattr function if the credential override is off or not. Reasoning is that the sepolicy check is unnecessary overhead, especially since the check can be expensive. Because for override credentials off, this affects _everyone_ that underneath performs private xattr calls without the appropriate sepolicy permissions and sys_admin capability. Providing blanket support for sys_admin would be bad for all possible callers. For the override credentials on, this will affect only the mounter, should it lack sepolicy permissions. Not considered a security problem since mounting by definition has sys_admin capabilities, but sepolicy contexts would still need to be crafted. It should be noted that there is precedence, __vfs_getxattr is used in other filesystems for their own internal trusted xattr management. Signed-off-by:Mark Salyzyn <salyzyn@android.com> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Amir Goldstein <amir73il@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: linux-unionfs@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kernel-team@android.com Cc: linux-security-module@vger.kernel.org (cherry picked from https://lore.kernel.org/lkml/20191104215253.141818-4-salyzyn@android.com/ ) Signed-off-by:
Mark Salyzyn <salyzyn@google.com> Bug: 133515582 Bug: 136124883 Bug: 129319403 Change-Id: I34d99cc46e9e87a79efc8d05f85980bbc137f7eb
Loading
Please register or sign in to comment