Summary: SELinux is preventing /sbin/cachefilesd "rmdir" access on @b5. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by cachefilesd. It is not expected that this access is required by cachefilesd 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 FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context unconfined_u:system_r:cachefilesd_t:s0 Target Context system_u:object_r:cachefiles_var_t:s0 Target Objects @b5 [ dir ] Source cachefilesd Source Path /sbin/cachefilesd Port <Unknown> Host (removed) Source RPM Packages cachefilesd-0.9-3.fc12 Target RPM Packages Policy RPM selinux-policy-3.7.15-4.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux barsoom.rdu.redhat.com 2.6.33-1.fc13.i686.PAE #1 SMP Wed Feb 24 19:54:49 UTC 2010 i686 i686 Alert Count 1 First Seen Thu 25 Mar 2010 07:58:52 AM EDT Last Seen Thu 25 Mar 2010 07:58:52 AM EDT Local ID 79f0fe73-7c4e-4c93-b5d1-b44886fef522 Line Numbers Raw Audit Messages node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518332.550:21841): avc: denied { rmdir } for pid=1670 comm="cachefilesd" name="@b5" dev=dm-0 ino=1177664 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=dir node=barsoom.rdu.redhat.com type=SYSCALL msg=audit(1269518332.550:21841): arch=40000003 syscall=301 success=yes exit=0 a0=b a1=90120d8 a2=200 a3=bf901a3b items=0 ppid=1 pid=1670 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cachefilesd" exe="/sbin/cachefilesd" subj=unconfined_u:system_r:cachefilesd_t:s0 key=(null) Hash String generated from catchall,cachefilesd,cachefilesd_t,cachefiles_var_t,dir,rmdir audit2allow suggests: #============= cachefilesd_t ============== allow cachefilesd_t cachefiles_var_t:dir rmdir;
Once I set it to permissive mode, there were also a bunch of errors from kslowd trying to access files under /var/fscache. For instance: node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.720:21872): avc: denied { read } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" dev=dm-0 ino=1177986 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.727:21873): avc: denied { create } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.727:21874): avc: denied { write } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" dev=dm-0 ino=1177986 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file
David shouldn't cacehfilesd has full access to manage_dirs_pattern(cachefilesd_t, cachefiles_var_t, cachefiles_var_t) manage_files_pattern(cachefilesd_t, cachefiles_var_t, cachefiles_var_t)
(In reply to comment #2) > David shouldn't cachefilesd have full access to > > manage_dirs_pattern(cachefilesd_t, cachefiles_var_t, cachefiles_var_t) > manage_files_pattern(cachefilesd_t, cachefiles_var_t, cachefiles_var_t) No. It specifically should not have any access to the contents of the files in the cache, and it should not be allowed to create any files, directories, symlinks, etc. therein. It is allowed to remove and rename stuff, to go into and read directories, and to read the stats and xattrs on files and dirs. That's about it wrt to the cache.
In cachefilesd.te, the following line: allow cachefilesd_t cachefiles_var_t : dir rw_dir_perms; should perhaps be: allow cachefilesd_t cachefiles_var_t : dir { rw_dir_perms getattr rename rmdir } ;
node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.720:21872): avc: denied { read } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" dev=dm-0 ino=1177986 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.727:21873): avc: denied { create } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.727:21874): avc: denied { write } for pid=913 comm="kslowd001" name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" dev=dm-0 ino=1177986 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file These indicate it is tryint to create/read/write the files also.
(In reply to comment #1) > Once I set it to permissive mode, there were also a bunch of errors from kslowd > trying to access files under /var/fscache. For instance: > > node=barsoom.rdu.redhat.com type=AVC msg=audit(1269518531.720:21872): avc: > denied { read } for pid=913 comm="kslowd001" > name="Ew0MDRj90KKpe302000g06hS8IE4Kb4gJ7kxo00008OjI0000" dev=dm-0 ino=1177986 > scontext=unconfined_u:system_r:cachefilesd_t:s0 > tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=file I think that's because you're still using cachefilesd-0.9. cachefilesd-0.10 has the extra configuration option required for operation under SELinux included in /etc/cachefilesd.conf: http://git.kernel.org/?p=linux/kernel/git/dhowells/cachefilesd.git;a=commit;h=a1e0c562d83f721c7defd685dbcfd6013577b46b The problem is that, unless the cachefiles kernel module is told the security label under which it will operate, it will try to operate under the label of whoever gave it the 'bind' command - usually the cachefilesd program. The module supports a secctx option in its configuration that will tell it the security label it should be operating under, and the SELinux policy then passes judgement on whether this is permissible. This is documented here: http://git.kernel.org/?p=linux/kernel/git/dhowells/cachefilesd.git;a=commit;h=641e49724780cb1de46d9d431bd4152890f78a3a
Fixed in selinux-policy-3.7.16-1.fc13.noarch and cachefilesd-0.10
David, I'm currently using cachefilesd-0.9-3.fc12.i686 on this box. There doesn't seem to be a f13 cachefilesd package yet. Do you have plans to ship that version in f13?
F13 should have -0.10 (as RHEL-6 does). In fact, the policy in RHEL-6 probably needs updating too.
selinux-policy-3.7.16-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/selinux-policy-3.7.16-1.fc13
Ok, got cachefilesd-0.10 installed by building the package out of -devel for F13. The cachefilesd-selinux package there conflicts with the selinux packages in F13 however, so I had to install with --nodeps. Seems to work correctly with selinux now.
selinux-policy-3.7.16-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.7.16-2.fc13
Where did selinux-policy-3.7.16-2.fc13 go? The URL above gives "The path /updates/selinux-policy-3.7.16-2.fc13 cannot be found". I'm on F13-Beta.RC5 and still with cachefilesd-0.9-3.fc12 resp. selinux-policy-3.7.15-4.fc13, with the updates-testing repo enabled.
Something must have hung up the system. I just pushed selinux-policy-3.7.17-6.fc13 to testing. And selinux-policy-3.7.18-1.fc13 is in koji
Still an issue with selinux-policy-3.7.19-2.fc13, although for "create_files_as" (and not rmdir) this time: Apr 21 13:46:04 disko cachefilesd[3249]: About to bind cache Apr 21 13:46:04 disko kernel: CacheFiles: Security denies permission to make dirs: error -13 Apr 21 13:46:04 disko cachefilesd[3249]: CacheFiles bind failed: errno 13 (Permission denied) Apr 21 13:46:04 disko kernel: CacheFiles: Failed to register: -13 Summary: SELinux is preventing /sbin/cachefilesd "create_files_as" access . Detailed Description: SELinux denied access requested by cachefilesd. It is not expected that this access is required by cachefilesd 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. Additional Information: Source Context unconfined_u:system_r:cachefilesd_t:s0 Target Context unconfined_u:object_r:var_t:s0 Target Objects None [ kernel_service ] Source cachefilesd Source Path /sbin/cachefilesd Port <Unknown> Host disko.int.consol.us Source RPM Packages cachefilesd-0.9-3.fc12 Target RPM Packages Policy RPM selinux-policy-3.7.19-2.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name disko.int.consol.us Platform Linux disko.int.consol.us 2.6.33.2-57.fc13.x86_64 #1 SMP Tue Apr 20 08:57:50 UTC 2010 x86_64 x86_64 Alert Count 2 First Seen Wed 21 Apr 2010 01:46:04 PM PDT Last Seen Wed 21 Apr 2010 01:46:04 PM PDT Local ID 79f2ecb8-cc7b-486a-a82f-e35869e94511 Line Numbers Raw Audit Messages node=disko.int.consol.us type=AVC msg=audit(1271882764.570:23518): avc: denied { create_files_as } for pid=3249 comm="cachefilesd" scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=kernel_service node=disko.int.consol.us type=AVC msg=audit(1271882764.570:23518): avc: denied { add_name } for pid=3249 comm="cachefilesd" name="fscache" dev=sda3 ino=265798 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=dir node=disko.int.consol.us type=SYSCALL msg=audit(1271882764.570:23518): arch=c000003e syscall=1 success=no exit=-13 a0=3 a1=4042a1 a2=4 a3=7fffa2c77d40 items=0 ppid=3248 pid=3249 auid=1002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cachefilesd" exe="/sbin/cachefilesd" subj=unconfined_u:system_r:cachefilesd_t:s0 key=(null)
Where is the fscache directory located? It looks like it is mislabeled. restorecon -R -v /var/fscache Should fix.
/var/fscache should be included in the cachefilesfd payload
Adding allow cachefilesd_t file_type:kernel_service create_as_is; Fixed in selinux-policy-3.7.19-5.fc13.noarch
After installing cachefilesd, cachefilesd.conf pointed to the non-existant /var/fscache. As I tend to have the cache under /var/cache/fscache on other boxen, I did "mkdir -m0700 /var/cache/fscache" and assumed selinux-policy would magically handle this as a valid argument for cachefilesd. I did "restorecon -R -v /var/cache/fscache", but the SELinux error persists and cachefilesd won't start :-\ Am I bound to have the cachedirectory under /var/fscache, even with the new selinux-policy-3.7.19-5?
# semanage fcontext -a -t cachefiles_var_t '/var/cache/fscache(/.*)?' # restorecon -R -v /var/cache/fscache I prefer this path also. I think cachefilesd should change to this.
OK, I admit: my SELinux-fu is pretty much non-existant, so thanks for navigating me through this. I still think this bug report is valid, as I'd expect *) cachefilesd to work after installation. For the sake of "let's try how it's supposed to work" I tried to get cachefilesd running with standard /var/fscache and deal with a different cachedir later on: # mkdir -m0700 /var/fscache # restorecon -R -v /var/fscache restorecon reset /var/fscache context unconfined_u:object_r:var_t:s0->system_u:object_r:cachefiles_var_t:s0 But cachefilesd would not start, it needs "create" access too: ------------------------------------------------------------- SELinux is preventing /sbin/cachefilesd "create" access on fscache Raw Audit Messages node=disko.int.consol.us type=AVC msg=audit(1271963784.881:24400): avc: denied { create } for pid=5603 comm="cachefilesd" name="fscache" dev=sda3 ino=395213 scontext=unconfined_u:system_r:cachefilesd_t:s0 tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=dir node=disko.int.consol.us type=SYSCALL msg=audit(1271963784.881:24400): arch=c000003e syscall=1 success=no exit=-13 a0=3 a1=4042a1 a2=4 a3=4000 items=0 ppid=5602 pid=5603 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=17 comm="cachefilesd" exe="/sbin/cachefilesd" subj=unconfined_u:system_r:cachefilesd_t:s0 key=(null) ------------------------------------------------------------- The same happens for /var/cache/fscache after semanage/restorecon has been run. *) well, as much as anyone can "expect" from an opensource project anyway :-)
Remember this is an open source project which has not even been released yet. :^) David, your policy excluded the ability for cachefilesd_t to create directories in cachefiles_var_t? Was this a mistake?
(In reply to comment #21) > But cachefilesd would not start, it needs "create" access too: cachefilesd will only create one thing - and that's its pid file, but that doesn't seem to be the issue here. That's covered by different security labels and has a different filename to that appearing in the audit log. > node=disko.int.consol.us type=AVC msg=audit(1271963784.881:24400): avc: denied > { create } for pid=5603 comm="cachefilesd" name="fscache" dev=sda3 ino=395213 > scontext=unconfined_u:system_r:cachefilesd_t:s0 > tcontext=system_u:object_r:cachefiles_var_t:s0 tclass=dir Can you show me what's in your /etc/cachefilesd.conf? And am I right in thinking you have the cachefilesd-0.9 RPM installed, not the cachefilesd-0.10 RPM? Do you have: secctx system_u:system_r:cachefiles_kernel_t:s0 in your config file? If you don't have that, the kernel module will try and use cachefilesd's security context for accessing the cache, rather than its own. > node=disko.int.consol.us type=SYSCALL msg=audit(1271963784.881:24400): > arch=c000003e syscall=1 ... The syscall number seems to indicate this is an exit syscall.
# rpm -q cachefilesd cachefilesd-0.9-3.fc12.x86_64 I installed via the FC13-RC5 iso and upgrading quite often since then. Where can I find cachefilesd-0.10? # grep ^[a-z] /etc/cachefilesd.conf dir /var/cache/fscache tag mycache brun 10% bcull 7% bstop 3% frun 10% fcull 7% fstop 3% # ls -ldZ /var/cache/fscache /var/run/ drwx------. root root system_u:object_r:cachefiles_var_t:s0 /var/cache/fscache drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /var/run/ No, I did not have the secctx option in my config file. But when I put it in, cachefilesd works! Thanks! So, I'd have to file a bug against cachefilesd then?
This bug is currently assigned to cachefilesd
cachefilesd-0.10.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/cachefilesd-0.10.1-1.fc13
cachefilesd-0.10.1-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.