| Message ID | 20201021151903.652827-3-salyzyn@android.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | overlayfs override_creds=off & nested get xattr fix | expand |
On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn <salyzyn@android.com> wrote: > > Because of the overlayfs getxattr recursion, the incoming inode fails > to update the selinux sid resulting in avc denials being reported > against a target context of u:object_r:unlabeled:s0. > > Solution is to respond to the XATTR_NOSECURITY flag in get xattr > method that calls the __vfs_getxattr handler instead so that the > context can be read in, rather than being denied with an -EACCES > when vfs_getxattr handler is called. > > For the use case where access is to be blocked by the security layer. > > The path then would be security(dentry) -> > __vfs_getxattr({dentry...XATTR_NOSECURITY}) -> > handler->get({dentry...XATTR_NOSECURITY}) -> > __vfs_getxattr({realdentry...XATTR_NOSECURITY}) -> > lower_handler->get({realdentry...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 to the logs and > the caller that the target context was blocked. > > For selinux this would solve the cosmetic issue of the selinux log > and allow audit2allow to correctly report the rule needed to address > the access problem. > > 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_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. This would be a problem when unprivileged mounting of overlay is introduced. I'd really like to avoid weakening the current security model. The big API churn in the 1/4 patch also seems excessive considering that this seems to be mostly a cosmetic issue for android. Am I missing something? Thanks, Miklos
On 10/30/20 8:07 AM, Miklos Szeredi wrote: > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn <salyzyn@android.com> wrote: >> Because of the overlayfs getxattr recursion, the incoming inode fails >> to update the selinux sid resulting in avc denials being reported >> against a target context of u:object_r:unlabeled:s0. >> >> Solution is to respond to the XATTR_NOSECURITY flag in get xattr >> method that calls the __vfs_getxattr handler instead so that the >> context can be read in, rather than being denied with an -EACCES >> when vfs_getxattr handler is called. >> >> For the use case where access is to be blocked by the security layer. >> >> The path then would be security(dentry) -> >> __vfs_getxattr({dentry...XATTR_NOSECURITY}) -> >> handler->get({dentry...XATTR_NOSECURITY}) -> >> __vfs_getxattr({realdentry...XATTR_NOSECURITY}) -> >> lower_handler->get({realdentry...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 to the logs and >> the caller that the target context was blocked. >> >> For selinux this would solve the cosmetic issue of the selinux log >> and allow audit2allow to correctly report the rule needed to address >> the access problem. >> >> 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_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. > This would be a problem when unprivileged mounting of overlay is > introduced. I'd really like to avoid weakening the current security > model. The current security model does not deal with non-overlapping security contexts between init (which on android has MAC permissions only when necessary, only enough permissions to perform the mount and other mundane operations, missing exec and read permissions in key spots) and user calls. We are only weakening (that is actually an incorrect statement, security is there, just not double security of both mounter and caller) the security around calls that retrieve the xattr for administrative and internal purposes. No data is exposed to the caller that it would not otherwise have permissions for. This patch becomes necessary when matched with the PATCH v18 3/4 of the series which fixes the user space break introduced in ~4.6 that formerly used the callers credentials for all accesses in all places. Security is weakened already as-is in overlayfs with all the overriding of the credentials for internal accesses to overlayfs mechanics based on the mounter credentials. Using the mounter credentials as a wider security hole is the problem, at least with PATCH v18 3/4 of the series we go back optionally to only using the caller's credentials to perform the operations. Admittedly some of the internal operations like mknod are privileged, but at least in Android's use case we are not using them with callers without the necessary credentials. Android does not give the mounter more credentials than the callers, there is very little overlap in the MAC security. > The big API churn in the 1/4 patch also seems excessive considering > that this seems to be mostly a cosmetic issue for android. Am I > missing something? Breaks sepolicy, it no longer has access to the context data at the overlayfs security boundary. unknown is a symptom of being denied based on the denial to xattr data from the underlying filesystem layer. Being denied the security context of the target is not a good thing within the sepolicy security layer. > > Thanks, > Miklos
On 2020-10-30 09:00:35, Mark Salyzyn wrote: > On 10/30/20 8:07 AM, Miklos Szeredi wrote: > > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn <salyzyn@android.com> wrote: > > > Because of the overlayfs getxattr recursion, the incoming inode fails > > > to update the selinux sid resulting in avc denials being reported > > > against a target context of u:object_r:unlabeled:s0. > > > > > > Solution is to respond to the XATTR_NOSECURITY flag in get xattr > > > method that calls the __vfs_getxattr handler instead so that the > > > context can be read in, rather than being denied with an -EACCES > > > when vfs_getxattr handler is called. > > > > > > For the use case where access is to be blocked by the security layer. > > > > > > The path then would be security(dentry) -> > > > __vfs_getxattr({dentry...XATTR_NOSECURITY}) -> > > > handler->get({dentry...XATTR_NOSECURITY}) -> > > > __vfs_getxattr({realdentry...XATTR_NOSECURITY}) -> > > > lower_handler->get({realdentry...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 to the logs and > > > the caller that the target context was blocked. > > > > > > For selinux this would solve the cosmetic issue of the selinux log > > > and allow audit2allow to correctly report the rule needed to address > > > the access problem. > > > > > > 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_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. > > This would be a problem when unprivileged mounting of overlay is > > introduced. I'd really like to avoid weakening the current security > > model. > > The current security model does not deal with non-overlapping security > contexts between init (which on android has MAC permissions only when > necessary, only enough permissions to perform the mount and other mundane > operations, missing exec and read permissions in key spots) and user calls. > > We are only weakening (that is actually an incorrect statement, security is > there, just not double security of both mounter and caller) the security > around calls that retrieve the xattr for administrative and internal > purposes. No data is exposed to the caller that it would not otherwise have > permissions for. We've ran into the same issues that Mark is trying to solve with this series. I came across Mark's series while searching around before I wrote up a similar patch to Mark's patch #3. We have a confined process that sets up Overlayfs mounts, then that process starts a service confined by another security context, then that service may execute binaries that run under a third security context. In this case, I'm talking about SELinux security contexts but it could be AppArmor or anything else that you use to separate out privileges/permissions at fine-grained detail. We don't want to grant all the privileges/permissions required by the service (and its helper utilities) to the process that sets up the Overlayfs mounts because we've been very careful in separating them apart with security policy. However, we want to make use of Overlayfs and adding a mount option to bypass the check on the mounter's cred seems like a safe way of using Overlayfs without violating our principle of least privilege. Tyler > > This patch becomes necessary when matched with the PATCH v18 3/4 of the > series which fixes the user space break introduced in ~4.6 that formerly > used the callers credentials for all accesses in all places. Security is > weakened already as-is in overlayfs with all the overriding of the > credentials for internal accesses to overlayfs mechanics based on the > mounter credentials. Using the mounter credentials as a wider security hole > is the problem, at least with PATCH v18 3/4 of the series we go back > optionally to only using the caller's credentials to perform the operations. > Admittedly some of the internal operations like mknod are privileged, but at > least in Android's use case we are not using them with callers without the > necessary credentials. > > Android does not give the mounter more credentials than the callers, there > is very little overlap in the MAC security. > > > The big API churn in the 1/4 patch also seems excessive considering > > that this seems to be mostly a cosmetic issue for android. Am I > > missing something? > > Breaks sepolicy, it no longer has access to the context data at the > overlayfs security boundary. > > unknown is a symptom of being denied based on the denial to xattr data from > the underlying filesystem layer. Being denied the security context of the > target is not a good thing within the sepolicy security layer. > > > > > Thanks, > > Miklos > >
On 2021-02-05 12:01:55, Tyler Hicks wrote: > On 2020-10-30 09:00:35, Mark Salyzyn wrote: > > On 10/30/20 8:07 AM, Miklos Szeredi wrote: > > > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn <salyzyn@android.com> wrote: > > > > Because of the overlayfs getxattr recursion, the incoming inode fails > > > > to update the selinux sid resulting in avc denials being reported > > > > against a target context of u:object_r:unlabeled:s0. > > > > > > > > Solution is to respond to the XATTR_NOSECURITY flag in get xattr > > > > method that calls the __vfs_getxattr handler instead so that the > > > > context can be read in, rather than being denied with an -EACCES > > > > when vfs_getxattr handler is called. > > > > > > > > For the use case where access is to be blocked by the security layer. > > > > > > > > The path then would be security(dentry) -> > > > > __vfs_getxattr({dentry...XATTR_NOSECURITY}) -> > > > > handler->get({dentry...XATTR_NOSECURITY}) -> > > > > __vfs_getxattr({realdentry...XATTR_NOSECURITY}) -> > > > > lower_handler->get({realdentry...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 to the logs and > > > > the caller that the target context was blocked. > > > > > > > > For selinux this would solve the cosmetic issue of the selinux log > > > > and allow audit2allow to correctly report the rule needed to address > > > > the access problem. > > > > > > > > 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_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. > > > This would be a problem when unprivileged mounting of overlay is > > > introduced. I'd really like to avoid weakening the current security > > > model. > > > > The current security model does not deal with non-overlapping security > > contexts between init (which on android has MAC permissions only when > > necessary, only enough permissions to perform the mount and other mundane > > operations, missing exec and read permissions in key spots) and user calls. > > > > We are only weakening (that is actually an incorrect statement, security is > > there, just not double security of both mounter and caller) the security > > around calls that retrieve the xattr for administrative and internal > > purposes. No data is exposed to the caller that it would not otherwise have > > permissions for. > > We've ran into the same issues that Mark is trying to solve with this > series. I came across Mark's series while searching around before I > wrote up a similar patch to Mark's patch #3. > > We have a confined process that sets up Overlayfs mounts, then that process > starts a service confined by another security context, then that service > may execute binaries that run under a third security context. In this > case, I'm talking about SELinux security contexts but it could be > AppArmor or anything else that you use to separate out > privileges/permissions at fine-grained detail. > > We don't want to grant all the privileges/permissions required by the > service (and its helper utilities) to the process that sets up the > Overlayfs mounts because we've been very careful in separating them > apart with security policy. However, we want to make use of Overlayfs > and adding a mount option to bypass the check on the mounter's cred > seems like a safe way of using Overlayfs without violating our principle > of least privilege. I just realized that I missed one noteworthy aspect of our use case. We would be alright if this functionality to bypass the mounter's cred checks (conditional, based on a mount option) was only allowed for read-only overlays[1]. I'm not sure if that would meet the needs of Android. Can you comment on that, Mark? Miklos, would that restriction make this series any more acceptable to you? Thanks! Tyler [1] https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#multiple-lower-layers > > Tyler > > > > > This patch becomes necessary when matched with the PATCH v18 3/4 of the > > series which fixes the user space break introduced in ~4.6 that formerly > > used the callers credentials for all accesses in all places. Security is > > weakened already as-is in overlayfs with all the overriding of the > > credentials for internal accesses to overlayfs mechanics based on the > > mounter credentials. Using the mounter credentials as a wider security hole > > is the problem, at least with PATCH v18 3/4 of the series we go back > > optionally to only using the caller's credentials to perform the operations. > > Admittedly some of the internal operations like mknod are privileged, but at > > least in Android's use case we are not using them with callers without the > > necessary credentials. > > > > Android does not give the mounter more credentials than the callers, there > > is very little overlap in the MAC security. > > > > > The big API churn in the 1/4 patch also seems excessive considering > > > that this seems to be mostly a cosmetic issue for android. Am I > > > missing something? > > > > Breaks sepolicy, it no longer has access to the context data at the > > overlayfs security boundary. > > > > unknown is a symptom of being denied based on the denial to xattr data from > > the underlying filesystem layer. Being denied the security context of the > > target is not a good thing within the sepolicy security layer. > > > > > > > > Thanks, > > > Miklos > > > >
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index b584dca845ba..2b14291beb86 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -378,7 +378,7 @@ int ovl_xattr_set(struct dentry *dentry, struct inode *inode, const char *name, } int ovl_xattr_get(struct dentry *dentry, struct inode *inode, const char *name, - void *value, size_t size) + void *value, size_t size, int flags) { ssize_t res; const struct cred *old_cred; @@ -386,7 +386,8 @@ int ovl_xattr_get(struct dentry *dentry, struct inode *inode, const char *name, ovl_i_dentry_upper(inode) ?: ovl_dentry_lower(dentry); old_cred = ovl_override_creds(dentry->d_sb); - res = vfs_getxattr(realdentry, name, value, size); + res = __vfs_getxattr(realdentry, d_inode(realdentry), name, + value, size, flags); revert_creds(old_cred); return res; } diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h index f8880aa2ba0e..06db4cf87f55 100644 --- a/fs/overlayfs/overlayfs.h +++ b/fs/overlayfs/overlayfs.h @@ -184,7 +184,9 @@ static inline ssize_t ovl_do_getxattr(struct ovl_fs *ofs, struct dentry *dentry, size_t size) { const char *name = ovl_xattr(ofs, ox); - return vfs_getxattr(dentry, name, value, size); + struct inode *ip = d_inode(dentry); + + return __vfs_getxattr(dentry, ip, name, value, size, XATTR_NOSECURITY); } static inline int ovl_do_setxattr(struct ovl_fs *ofs, struct dentry *dentry, @@ -439,7 +441,7 @@ int ovl_permission(struct inode *inode, int mask); int ovl_xattr_set(struct dentry *dentry, struct inode *inode, const char *name, const void *value, size_t size, int flags); int ovl_xattr_get(struct dentry *dentry, struct inode *inode, const char *name, - void *value, size_t size); + void *value, size_t size, int flags); ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size); struct posix_acl *ovl_get_acl(struct inode *inode, int type); int ovl_update_time(struct inode *inode, struct timespec64 *ts, int flags); diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index f41353ba1e68..d447958badc2 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -930,7 +930,7 @@ ovl_posix_acl_xattr_get(const struct xattr_handler *handler, struct dentry *dentry, struct inode *inode, const char *name, void *buffer, size_t size, int flags) { - return ovl_xattr_get(dentry, inode, handler->name, buffer, size); + return ovl_xattr_get(dentry, inode, handler->name, buffer, size, flags); } static int __maybe_unused @@ -1012,7 +1012,7 @@ static int ovl_other_xattr_get(const struct xattr_handler *handler, const char *name, void *buffer, size_t size, int flags) { - return ovl_xattr_get(dentry, inode, name, buffer, size); + return ovl_xattr_get(dentry, inode, name, buffer, size, flags); } static int ovl_other_xattr_set(const struct xattr_handler *handler,
Because of the overlayfs getxattr recursion, the incoming inode fails to update the selinux sid resulting in avc denials being reported against a target context of u:object_r:unlabeled:s0. Solution is to respond to the XATTR_NOSECURITY flag in get xattr method that calls the __vfs_getxattr handler instead so that the context can be read in, rather than being denied with an -EACCES when vfs_getxattr handler is called. For the use case where access is to be blocked by the security layer. The path then would be security(dentry) -> __vfs_getxattr({dentry...XATTR_NOSECURITY}) -> handler->get({dentry...XATTR_NOSECURITY}) -> __vfs_getxattr({realdentry...XATTR_NOSECURITY}) -> lower_handler->get({realdentry...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 to the logs and the caller that the target context was blocked. For selinux this would solve the cosmetic issue of the selinux log and allow audit2allow to correctly report the rule needed to address the access problem. 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_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: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: kernel-team@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: Stephen Smalley <sds@tycho.nsa.gov> Cc: linux-doc@vger.kernel.org Cc: selinux@vger.kernel.org v18 - correct inode argument to __vfs_getxattr v17 - rebase and add inode argument to __vfs_getxattr v16 - rebase and merge internal getxattr operations patch v15 - revert to v13 because xattr_gs_args rejected. v14 - rebase to use xattr_gs_args. v13 - rebase to use __vfs_getxattr flags option. v12 - Added back to patch series as get xattr with flag option. v11 - Squashed out of patch series and replaced with per-thread flag solution. v10 - Added to patch series as __get xattr method. --- fs/overlayfs/inode.c | 5 +++-- fs/overlayfs/overlayfs.h | 6 ++++-- fs/overlayfs/super.c | 4 ++-- 3 files changed, 9 insertions(+), 6 deletions(-)