Description of problem: In RHEL5 Beta2 snapshot5 (kernel version : 2.6.18-1.2910), SELinux blocks "cp" command's "-a" option, but allows the equivalent "-dpR" options(enable SELinux, use Enforcing). If run "cp -a", user will get a "Permission denied" error. Is this an intended change or it is a bug ? Former RHEL5 snapshots do not have this limitation.
Forget to mention that, SELinux only blocks "cp -a" when copying files from CD/DVD disks, following is the selinux_alert.txt: Summary SELinux is preventing /bin/cp (iso9660_t) "associate" to device-copy (fs_t). Detailed Description SELinux denied access requested by /bin/cp. It is not expected that this access is required by /bin/cp and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:object_r:iso9660_t Target Context system_u:object_r:fs_t Target Objects device-copy [ filesystem ] Affected RPM Packages coreutils-5.97-12.1.el5 [application] Policy RPM selinux-policy-2.4.6-15.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name dhcp-0-088.pek.redhat.com Platform Linux dhcp-0-088.pek.redhat.com 2.6.18-1.2910.el5xen #1 SMP Fri Dec 15 22:46:03 EST 2006 i686 i686 Alert Count 3 Line Numbers Raw Audit Messages avc: denied { associate } for comm="cp" egid=0 euid=0 exe="/bin/cp" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="device-copy" pid=22448 scontext=system_u:object_r:iso9660_t:s0 sgid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 suid=0 tclass=filesystem tcontext=system_u:object_r:fs_t:s0 tty=pts4 uid=0
Yes we are familiar with the problem and are taking a two prong approach to the problem. One is to replace the setroubleshoot message with: Summary SELinux is preventing /bin/cp from creating a file with a context of iso9660_t on a filesystem. Detailed Description SELinux is preventing /bin/cp from creating a file with a context of iso9660_t on a filesystem. Usually this happens when you ask the cp commnad to maintain the context of a file when copying between file systems. "cp -a" for example. Not all file context should be maintained between the file systems. For example a readonly file type like iso9660_t should not be placed on a r/w system. cp -P might be a better solution, as this will adopt the default file context for the destination. Allowing Access Use a command like cp -P to preserve all permissions except SELinux context. Additional Information Source Context system_u:object_r:iso9660_t Target Context system_u:object_r:fs_t Target Objects /root/Setup.exe [ filesystem ] Affected RPM Packages coreutils-5.97-12.1.el5 [application] Policy RPM selinux-policy-2.4.6-24 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.filesystem_associate Host Name redsox.boston.devel.redhat.com Platform Linux redsox.boston.devel.redhat.com 2.6.18-1.2961.el5 #1 SMP Wed Jan 3 14:35:29 EST 2007 i686 i686 Alert Count 1 Line Numbers Raw Audit Messages avc: denied { associate } for comm="cp" cwd="/media/HPG54_SW101" dev=fd:00 egid=0 euid=0 exe="/bin/cp" exit=-13 fsgid=0 fsuid=0 gid=0 inode=10911745 item=0 items=1 mode=040750 name="Setup.exe" obj=root:object_r:user_home_dir_t:s0 ogid=0 ouid=0 path="/root/Setup.exe" pid=3964 rdev=00:00 scontext=system_u:object_r:iso9660_t:s0 sgid=0 subj=user_u:system_r:unconfined_t:s0 suid=0 tclass=filesystem tcontext=system_u:object_r:fs_t:s0 tty=pts0 uid=0 We also plan on updating the cp man page.
So, this means to block "cp -a" from CD/DVDs in SELinux is an intended change ? We're not allowed to "cp -a" from iso9660 media in RHEL5(with default SELinux policy) any more ?
*** This bug has been marked as a duplicate of 219900 ***