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 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. ;-)
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 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. ;-)
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:
- 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?
- 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.
- 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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Joe Cooper -
Karsten Wade