On 2015-09-21 16:47, Stephen Smalley wrote:
[...]
> >> This problem *ONLY* occurs in the initrd,
> >> which is *BEFORE* the SELinux policy loads.
> >> I'm not sure if this is relevant.
> >
> > Yes, I believe it is. Most likely culprit is:
> > security/selinux/hooks.c:
> > 2890 static int selinux_inode_setxattr(struct dentry *dentry, const
> > char *name,
> > 2891 const void *value, size_t
> > size, int flags)
> > 2892 {
> > 2893 struct inode *inode = dentry->d_inode;
> > 2894 struct inode_security_struct *isec = inode->i_security;
> > 2895 struct superblock_security_struct *sbsec;
> > 2896 struct common_audit_data ad;
> > 2897 u32 newsid, sid = current_sid();
> > 2898 int rc = 0;
> > 2899
> > 2900 if (strcmp(name, XATTR_NAME_SELINUX))
> > 2901 return selinux_inode_setotherxattr(dentry, name);
> > 2902
> > 2903 sbsec = inode->i_sb->s_security;
> > 2904 if (!(sbsec->flags & SBLABEL_MNT))
> > 2905 return -EOPNOTSUPP;
> > ^^^^^^^^^^^^
> > That's to prevent setting SELinux attributes on a filesystem that does
> > not support labeling due to use of a context= mount or policy genfscon
> > rules to override any xattrs on the filesystem. Maybe that should be
> > exempted if no policy is loaded (!ss_initialized).
> >
> > At this point, I have to ask: which is easier, patching systemd to do
> > what you want, loading policy earlier (in general, the earlier you load
> > SELinux policy, the better), or patching the kernel.
>
> BTW, IIUC, the reason that this manifests on an open(2) call is that
> overlayfs is trying to copy-up any xattrs from the lower filesystem to
> the upper filesystem when you touch the file, which triggers a
> vfs_getxattr on the lower filesystem and then a vfs_setxattr on the
> upper filesystem, and then we fail here. Not something we would see on
> open(2) otherwise.
Thanks for your response Stephen!
Let me confirm I understand correctly. The problem doesn't occur when I
write a file to the root of the overlay mountpoint. Are you saying this
is because I'm not attempting to copy/set ant SELinux attributes on this
file, but when I write something to /etc or /home, copy-up attempts and
fails to write the SELinux attribute xattr?
As for possible solutions: I'm not sure I want to contemplate patching
systemd, so I'll leave that as a last resort.
I'm happy to investigate loading the policy earlier; I'll need to talk
to some Debian SELinux people to understand better how the policy gets
loaded so I can duplicate that functionality into the initrd; I'm still
getting my head around SELinux.
Your final suggestion was a kernel change (!ss_initialized). Are you
suggesting this is something you'd consider changing in mainline, or
something I might want to patch for my specific instance? I want to
avoid the latter, but if you think the former may be sensible, that'd be
cool. Would that mean, however, that SELinux attributes may not be set
correctly and that the files create wouldn't be accessible by everything
that needs them after the policy has loaded?
--
Regards,
Matthew Cengia
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
