rsync, xattrs, ntfs-3g and "selinux.selinux"

[Daniel J Walsh]

Tom London wrote:
> On Wed, Sep 3, 2008 at 8:55 AM, James Antill <jantill at redhat.com> wrote:
>> On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote:
>>
>>> Looks like an rsync bug?
>>>
>>> James did you work on rsync?
>>  Nope, looking at the rpm changelog shows:
>>
>>
>> * Mon Feb 19 2007 Simo Sorce <ssorce at redhat.com> - 2.6.9-2
>> - fix acl/xattr bug with --delete: (bz#229145)
>>
>> [...]
>>
>> * Fri Jun 09 2006 Jay Fenlason <fenlason at redhat.com> 2.6.8-3
>> - Add my xattrs_bug patch to fix a bug where xattrs don't get sent
>> correctly.
>> [...]
>>
>> * Mon May 08 2006 Jay Fenlason <fenlason at redhat.com> 2.6.8-2
>> - New upstream release
>> - Use the upstream xattr patch instead of mine.  This closes
>>  bz#190208 CVE-2006-2083 rsync buffer overflow issue
>>
>> [...]
>>
>> * Thu Feb 10 2005 Jay Fenlason <fenlason at redhat.com> 2.6.3-2
>> - Added my -xattr patch, which is based on the -acl patch.
>>
>>
>> --
>> James Antill <jantill at redhat.com>
>> Red Hat
>>
> I looked into this a bit.....
> 
> The upstream source for rsync-3.0.3 shows this in xattr.c:
> <<<<SNIP>>>>>
> static int rsync_xal_set(const char *fname, item_list *xalp,
>                          const char *fnamecmp, stat_x *sxp)
> {
> <<<<<SNIP>>>>>
>         /* Remove any extraneous names. */
>         for (name = namebuf; list_len > 0; name += name_len) {
>                 name_len = strlen(name) + 1;
>                 list_len -= name_len;
> 
> #ifdef HAVE_LINUX_XATTRS
>                 /* We always ignore the system namespace, and non-root
>                  * ignores everything but the user namespace. */
>                 if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
>                             : !HAS_PREFIX(name, USER_PREFIX))
>                         continue;
> #endif
> 
> I think this says: if running as root, don't remove attributes in the
> system namespace (but remove everything else); if running as non-root,
> remove all attributes but those in the user namespace.
> 
> If so, when running as root, the code will attempt to remove
> attributes from the security namespace (e.g., 'security.selinux').
> 
> In my case, I'm rsync-ing to an ext4 fs that supports SELinux
> labels/etc., but copying from an NTFS-3g fs (mounted as /mnt/XXXXX)
> that shows fusefs_t as labels.  "getfattr" on files in these mounted
> filesystems fail:
> 
> [root at tlondon ~]# getfattr /mnt/music
> getfattr: /mnt/music: Operation not supported
> [root at tlondon ~]#
> 
> My (first?) guess is that rsync is trying to remove the security
> attributes from target files to match the source file attributes
> (none).
> 
> Is this logic wrong?  Should rsync try to remove the security (e.g.,
> selinux) attributes from the target?
> 
> It would be straightforward to patch the above code to 'continue' on
> both system and security attributes.  Something like:
> 
> --- xattrs.c	2008-09-06 11:12:50.000000000 -0700
> +++ xattrs.c.orig	2008-09-06 11:09:08.000000000 -0700
> @@ -818,10 +818,9 @@
>  		list_len -= name_len;
> 
>  #ifdef HAVE_LINUX_XATTRS
> -		/* We always ignore the system and security namespaces,
> -		 * and non-root ignores everything but the user namespace. */
> -		if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX)
> -				|| HAS_PREFIX(name, SECURITY_PREFIX) )
> +		/* We always ignore the system namespace, and non-root
> +		 * ignores everything but the user namespace. */
> +		if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
>  			    : !HAS_PREFIX(name, USER_PREFIX))
>  			continue;
>  #endif
> 
> But is this the right way to handle attributes in the security
> namespace?  What about "Trusted extended attributes"?
> 
> If the above is "the right way", I can create a working patch and test.
> 
> If not, I could use some "enlightenment"..... ;)
> 
> tom
We should bring this conversation into a bugzilla.  Maybe discuss on
main selinux list also.