On Thu, Jul 25, 2019 at 6:03 PM Mark Salyzyn <salyzyn@xxxxxxxxxxx> wrote:
On 7/24/19 10:48 PM, Amir Goldstein wrote:Ahhh you are talking about getting the security.selinux.* xattrs?
On Wed, Jul 24, 2019 at 10:57 PM Mark Salyzyn <salyzyn@xxxxxxxxxxx> wrote:__vfs_getxattr (the way the security layer acquires the target sid
Because of the overlayfs getxattr recursion, the incoming inode failsThis description is too brief for me to understand the root problem.
to update the selinux sid resulting in avc denials being reported
against a target context of u:object_r:unlabeled:s0.
What's wring with the overlayfs getxattr recursion w.r.t the selinux
without recursing back to security to check the access permissions)
calls get xattr method, which in overlayfs calls vfs_getxattr on the
lower layer (which then recurses back to security to check permissions)
and reports back -EACCES if there was a denial (which is OK) and _no_
sid copied to caller's inode security data, bubbles back to the security
layer caller, which reports an invalid avc: message for
u:object_r:unlabeled:s0 (the uninitialized sid instead of the sid for
the lower filesystem target). The blocked access is 100% valid, it is
supposed to be blocked. This does however result in a cosmetic issue
that makes it impossible to use audit2allow to construct a rule that
would be usable to fix the access problem.
I was under the impression (Vivek please correct me if I wrong)
that overlayfs objects cannot have individual security labels and
the only way to label overlayfs objects is by mount options on the
entire mount? Or is this just for lower layer objects?
Anyway, the API I would go for is adding a @flags argument to
get() which can take XATTR_NOSECURITY akin to
FMODE_NONOTIFY, GFP_NOFS, meant to avoid recursions.