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!

[Joe Cooper]

Joe Cooper wrote:

>  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 
Just to add to this, I found an update in the testing directory for 
policycoreutils that fixes this segfault, so this aspect of the problem 
goes away.  However, I'm still losing the label on swap.state, and I've 
also noticed that I'm actually getting slightly different labels than 
/var/spool/squid:

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

So I've got root:object_r:squid_cache_t for /var/spool/squid (the one 
that works) and system_u:object_r:squid_cache_t for the one that 
doesn't, though the top level directory of /var/squid/squid is the same:

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

I have no clue where that root/system_u difference is coming from--I 
never have been able to figure out how this labeling happens.

Thanks for any clarification anyone might have for me.  My first foray 
into SELinux has been a harrowing experience...a week in and I still 
have only foggy notions of what's happening.  ;-)

[Karsten Wade]

On Tue, 2005-02-15 at 02:04 -0600, Joe Cooper wrote:
>  Joe Cooper wrote:
>  also noticed that I'm actually getting slightly different labels than 
>  /var/spool/squid:
>  
>  [root@localhost /]# ls -lZ /var/spool/squid
>  drwxr-xr-x  squid    squid    root:object_r:squid_cache_t      00
>  [root@localhost /]# ls -lZ /cache0
>  drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  00
>  
>  So I've got root:object_r:squid_cache_t for /var/spool/squid (the one 
>  that works) and system_u:object_r:squid_cache_t for the one that 
>  doesn't,  
That different field is for the SELinux identity, which doesn't come
much into play for the targeted policy.

You get 'system_u:object_r' when something has been created by a system
process, you get 'root:object_r' when something has been created by the
root user.  There is an actual SELinux user 'root' that corresponds to
the Linux user 'root'.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
               IT executives rate Red Hat #1 for value              
                 http://www.redhat.com/promo/vendor/

[Joe Cooper]

Karsten Wade wrote:
>  On Tue, 2005-02-15 at 02:04 -0600, Joe Cooper wrote:
>  
> >Joe Cooper wrote:
> >also noticed that I'm actually getting slightly different labels than 
> >/var/spool/squid:
> >
> >[root@localhost /]# ls -lZ /var/spool/squid
> >drwxr-xr-x  squid    squid    root:object_r:squid_cache_t      00
> >[root@localhost /]# ls -lZ /cache0
> >drwxr-xr-x  squid    squid    system_u:object_r:squid_cache_t  00
> >
> >So I've got root:object_r:squid_cache_t for /var/spool/squid (the one 
> >that works) and system_u:object_r:squid_cache_t for the one that 
> >doesn't, 
>  
>  
>  That different field is for the SELinux identity, which doesn't come
>  much into play for the targeted policy.
>  
>  You get 'system_u:object_r' when something has been created by a system
>  process, you get 'root:object_r' when something has been created by the
>  root user.  There is an actual SELinux user 'root' that corresponds to
>  the Linux user 'root'. 
Thanks for that explanation, Karsten.  Some of these things are starting 
to make a bit of sense now.  ;-)

[Daniel J Walsh]

Joe Cooper wrote:

>  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
>  
The newer versions of restorecon allow you to specify 
file_contexts.local for things like this so you don't have to deal with 
sources.

>  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.
>  
Yes it should not need this.

>  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?
>  
Does /cache0 get deleted on reboot?  Is this on an ext3 file system?

>  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.
>  
restorecon fixed in update.
The only way you should loose the context is if you are using something 
other than ext2/3 for a file system or if the directory is being replaced
on every 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.
>  
I don't know, Are you starting the squid service while sitting on an NFS 
partition?  Any directories having anything to do with Squid on an NFS 
partition?

>  Thanks!
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list