Problems adding to targeted policy for a new cache directory for Squid
Joe Cooper
joe at swelltech.com
Tue Feb 15 07:49:31 UTC 2005
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 at localhost /]# ls -ldZ /cache0
drwxr-xr-x squid squid system_u:object_r:squid_cache_t /cache0
[root at 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 at localhost /]# restorecon -Rv /cache0
...
restorecon reset context /cache0/0F/FF:->system_u:object_r:squid_cache_t
Segmentation fault
[root at 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!
More information about the fedora-selinux-list
mailing list