Bug 576835

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.