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; :
Created attachment 635843 [details] File: type
Created attachment 635844 [details] File: hashmarkername
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.
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.
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.
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.
Eh, probably worth one of us looking into it first to make sure we're not doing something stupid by accident first.
anaconda-18.27-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.27-1.fc18
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).
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).
Confirmed this appears to be gone in Beta RC1. 18.28 went stable, closing.