Problems adding to targeted policy for a new cache directory for Squid

[Joe Cooper]

Hi all,

I'm running into some issues adding policy to cover some extra 
directories that we use on our systems.  I'm using FC3 and the latest 
errata targeted policy and kernel.  For our Squid process, we devote one 
or more partitions for cache storage, named /cache0, /cache1, and so on.

I've added the following line to file_contexts/program/squid.fc:

/cache.*(/.*)?                   system_u:object_r:squid_cache_t

Which matches the lines for /var/spool/squid(/.*)? and 
/var/cache/squid(/.*)?.  After running "restorecon -Rv /cache0", I have 
the right label on /cache0:

[root@localhost /]# ls -ldZ /cache0
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  /cache0
[root@localhost /]# ls -ldZ /var/spool/squid
drwxr-x---  squid    squid    system_u:object_r:squid_cache_t 
/var/spool/squid

However, when I start Squid I get a lot of avc: denied errors (I'm in 
permissive mode for testing).  Some of which don't even make any sense 
to me, like this one:

audit(1108452395.149:0): avc:  denied  { read } for  pid=3778 
exe=/usr/sbin/squid name=00 dev=hdc2 ino=5 
scontext=root:system_r:squid_t tcontext=root:object_r:nfs_t tclass=dir

This seems to indicate Squid needs to have nfs_t privileges, though I 
don't see why this should be so in the targeted policy.

If I run restorecon again (after creating the directories), I get a 
segfault and it stops before reaching the file(s) in the top level of 
the directory (there are subdirectories which all get relabeled).  i.e.:

[root@localhost /]# restorecon -Rv /cache0
...
restorecon reset context /cache0/0F/FF:->system_u:object_r:squid_cache_t
Segmentation fault
[root@localhost /]# ls -lZ /cache0
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  00
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  01
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  02
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  03
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  04
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  05
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  06
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  07
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  08
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  09
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0A
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0B
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0C
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0D
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0E
drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  0F
-rw-r--r--  squid    squid                                     swap.state

So swap.state is still unlabeled, and starting Squid leads to more avc: 
denied errores.  If I restorecon on just swap.state, Squid starts 
without errors, but after a reboot, the label is lost and Squid 
generates errors again.  I'll file an issue on the restorecon segfault, 
but that still probably doesn't solve all of my problems.

So, I'm quite stumped...I thought I had done what I needed to make this 
work, but clearly there's at least three things I don't understand:

1. Why does it lose the swap.state label on reboot?  Does restorecon run 
on every boot?

2. Why doesn't /var/spool/squid exhibit this same problem?  restorecon 
works without segfault, and doesn't lose the label on swap.state after a 
reboot.

3. Where is nfs_t coming from on /cache0?  It seems like some kind of 
default that it falls back to when a file is unlabeled, but I don't see 
anywhere that nfs_t is a generic label.

Thanks!