Bug 871637

Summary: SELinux is preventing /usr/bin/rsync from 'associate' accesses on the filesystem /sys.
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: dominick.grift, dwalsh, g.kaviyarasu, jonathan, mgrepl, stephent98, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:43c2590885ddda20e45bb9d6aa196c33eb3424e2c24e4932b40e64158cdedfd3
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-23 06:19:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: type
none
File: hashmarkername none

Description Adam Williamson 2012-10-30 22:45:23 UTC
Description of problem:
This AVC popped up during install from a pre-TC7 KDE live image I was testing (built myself with all current blocker/NTH-fixing updates). Just happened during the liveinst process, so far as I can make out.

Additional info:
libreport version: 2.0.17
kernel:         3.6.2-2.fc18.x86_64

description:
:SELinux is preventing /usr/bin/rsync from 'associate' accesses on the filesystem /sys.
:
:*****  Plugin filesystem_associate (99.5 confidence) suggests  ***************
:
:If you believe rsync should be allowed to create sys files
:Then you need to use a different command. You are not allowed to preserve the SELinux context on the target file system.
:Do
:use a command like "cp -p" to preserve all permissions except SELinux context.
:
:*****  Plugin catchall (1.49 confidence) suggests  ***************************
:
:If you believe that rsync should be allowed associate access on the sys filesystem by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:Do
:allow this access for now by executing:
:# grep rsync /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                unconfined_u:object_r:file_t:s0
:Target Context                system_u:object_r:sysfs_t:s0
:Target Objects                /sys [ filesystem ]
:Source                        rsync
:Source Path                   /usr/bin/rsync
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           rsync-3.0.9-3.fc18.x86_64
:Target RPM Packages           filesystem-3.1-2.fc18.x86_64
:Policy RPM                    selinux-policy-3.11.1-43.fc18.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Permissive
:Host Name                     (removed)
:Platform                      Linux (removed) 3.6.2-2.fc18.x86_64 #1 SMP Wed Oct
:                              17 05:56:07 UTC 2012 x86_64 x86_64
:Alert Count                   1
:First Seen                    2012-10-30 18:40:23 EDT
:Last Seen                     2012-10-30 18:40:23 EDT
:Local ID                      6667a595-8839-476c-8f23-6b32a5ad99ac
:
:Raw Audit Messages
:type=AVC msg=audit(1351636823.305:297): avc:  denied  { associate } for  pid=2191 comm="rsync" name="/" dev="sysfs" ino=1 scontext=unconfined_u:object_r:file_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem
:
:
:type=SYSCALL msg=audit(1351636823.305:297): arch=x86_64 syscall=lsetxattr success=yes exit=0 a0=7fff0f93f910 a1=13cccd0 a2=13cccb0 a3=20 items=0 ppid=2190 pid=2191 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm=rsync exe=/usr/bin/rsync subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null)
:
:Hash: rsync,file_t,sysfs_t,filesystem,associate
:
:audit2allow
:
:#============= file_t ==============
:allow file_t sysfs_t:filesystem associate;
:
:audit2allow -R
:
:#============= file_t ==============
:allow file_t sysfs_t:filesystem associate;
:

Comment 1 Adam Williamson 2012-10-30 22:45:26 UTC
Created attachment 635843 [details]
File: type

Comment 2 Adam Williamson 2012-10-30 22:45:28 UTC
Created attachment 635844 [details]
File: hashmarkername

Comment 3 Daniel Walsh 2012-10-31 10:41:38 UTC
THis AVC indicates that rsync is attempting to put down a file without a label or with file_t as a label on a file system that does not support labelling.  
rsync should not be attempting to write to /sys at all.

Comment 4 Adam Williamson 2012-11-01 00:42:55 UTC
It seems to happen consistently during live installs, so I'll take a guess at anaconda. Is anaconda rsyncing stuff to /sys during liveinst? If so, stoppit.

Comment 5 Chris Lumens 2012-11-01 21:07:17 UTC
We're using rsync, but we're passing it the -x option which is supposed to prevent rsync from traversing down into other filesystems.  And last I checked, /sys was a separate filesystem.

Comment 6 Adam Williamson 2012-11-01 21:39:34 UTC
When booted live, 'mount' claims:

sysfs on /sys type sysfs (rw,relatime,seclabel)

so that does seem like a 'separate filesystem', yeah. Should we assign to rsync?

manpage says:

       -x, --one-file-system
              This  tells  rsync  to avoid crossing a filesystem boundary when
              recursing.  This does not limit the user’s  ability  to  specify
              items  to copy from multiple filesystems, just rsync’s recursion
              through the hierarchy of each directory that the user specified,
              and  also  the  analogous recursion on the receiving side during
              deletion.  Also keep in mind that rsync treats a "bind" mount to
              the same device as being on the same filesystem.

Comment 7 Chris Lumens 2012-11-02 14:33:58 UTC
Eh, probably worth one of us looking into it first to make sure we're not doing something stupid by accident first.

Comment 8 Fedora Update System 2012-11-08 03:34:50 UTC
anaconda-18.27-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.27-1.fc18

Comment 9 Fedora Update System 2012-11-09 03:22:19 UTC
Package anaconda-18.27-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.27-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17823/anaconda-18.27-1.fc18
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-11-10 19:37:16 UTC
Package anaconda-18.28-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.28-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17823/anaconda-18.28-1.fc18
then log in and leave karma (feedback).

Comment 11 Adam Williamson 2012-11-23 06:19:30 UTC
Confirmed this appears to be gone in Beta RC1. 18.28 went stable, closing.