Hi all,
I've lots of problems related to SELinux on FC3...
I get tonnes of messages like
... audit(1102179993.228:0): avc: denied { append } for pid=2624 exe=/sbin/syslogd name=boot.log dev=md-6 ino=128104 scontex=root:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file syslog: /var/log/boot.log: Permissin denied ...
Same problem with dhcpd, portmap, etc. I've tried this
[root@murphy etc]# ls -alZ /var/log/boot.log -rw------- root root /var/log/boot.log
... and then this
[root@murphy etc]# chcon -t var_log_t /var/log/boot.log
but I always get the error message
"chcon: can't apply partial context to unlabeled file boot.log"
What I'm trying to understand is why system files like this are not already labeled as they should, and what I've to do to get my boxes working without complying...
Thanks for helping a poor novice, j3d.
I'm guessing that your filesystem is not labeled at all.
You can relabel your entire system by doing touch /.autorelabel and then rebooting or by running fixfiles relabel and then rebooting
That should get the labeling done on the boot up.
You may want to go get a cup of coffee, it will likely take a while (say, 10-20 minutes).
[The 'chcon' is failing because the SELinux label for /var/log/boot.log look something like: 'system_u:object_r:var_log_t'. You were only providing the last component ...]
tom
Thanks Tom,
the situation is now much better... I'm able to start squid, but I still get the following two error messages:
Starting squid: audit(1102241826.255.0): avc: denied { getattr } for pid=2435 exe=/usr/sbin/squid path=/boot dev=hda1 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:boot_t tclass=dir
audit(1102241826.255.0): avc: denied { getattr } for pid=2435 exe=/usr/sbin/squid path=/tmp dev=dm-3 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:tmp_t tclass=dir
It looks like there are problems with directories /boot and /tmp...
What's strange is that I get these error messages on a machine where I just upgraded from FC1 to FC3... I've also another machine on which I installed FC3 from scratch and here I've no problems at all.
j3d.
On Sat, 2004-12-04 at 16:34 -0800, Tom London wrote:
I'm guessing that your filesystem is not labeled at all.
You can relabel your entire system by doing touch /.autorelabel and then rebooting or by running fixfiles relabel and then rebooting
That should get the labeling done on the boot up.
You may want to go get a cup of coffee, it will likely take a while (say, 10-20 minutes).
[The 'chcon' is failing because the SELinux label for /var/log/boot.log look something like: 'system_u:object_r:var_log_t'. You were only providing the last component ...]
tom
On Sun, 05 Dec 2004 11:38:04 +0100, Giuseppe Greco giuseppe.greco@agamura.com wrote:
Thanks Tom,
the situation is now much better... I'm able to start squid, but I still get the following two error messages:
Starting squid: audit(1102241826.255.0): avc: denied { getattr } for pid=2435 exe=/usr/sbin/squid path=/boot dev=hda1 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:boot_t tclass=dir
audit(1102241826.255.0): avc: denied { getattr } for pid=2435 exe=/usr/sbin/squid path=/tmp dev=dm-3 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:tmp_t tclass=dir
It looks like there are problems with directories /boot and /tmp...
What's strange is that I get these error messages on a machine where I just upgraded from FC1 to FC3... I've also another machine on which I installed FC3 from scratch and here I've no problems at all.
I'm running strict/enforcing with latest Rawhide packages (selinux-policy-strict-1.19.10-4)
If I change to permissive mode (via 'setenforce 0') and start squid (via '/etc/init.d/squid start') I get the following:
Dec 5 09:47:34 fedora kernel: audit(1102268854.527:0): avc: denied { write } for pid=3455 exe=/bin/bash name=squid dev=hda2 ino=4457453 scontext=root:system_r:initrc_t tcontext=system_u:object_r:squid_log_t tclass=dir Dec 5 09:47:34 fedora kernel: audit(1102268854.527:0): avc: denied { add_name } for pid=3455 exe=/bin/bash name=squid.out scontext=root:system_r:initrc_t tcontext=system_u:object_r:squid_log_t tclass=dir Dec 5 09:47:34 fedora kernel: audit(1102268854.528:0): avc: denied { create } for pid=3455 exe=/bin/bash name=squid.out scontext=root:system_r:initrc_t tcontext=root:object_r:squid_log_t tclass=file Dec 5 09:47:35 fedora squid[3458]: Squid Parent: child process 3460 started
With squid successfully running.
This indicates that the policy may need some additional rules, like: allow initrc_t squid_log_t:dir { add_name write }; allow initrc_t squid_log_t:file create;
But I don't get the messages you get. I'm running squid-2.5.STABLE7-1. This the same as you?
tom
On Sun, 2004-12-05 at 09:57 -0800, Tom London wrote:
Dec 5 09:47:34 fedora kernel: audit(1102268854.527:0): avc: denied { write } for pid=3455 exe=/bin/bash name=squid dev=hda2 ino=4457453 scontext=root:system_r:initrc_t tcontext=system_u:object_r:squid_log_t tclass=dir Dec 5 09:47:34 fedora kernel: audit(1102268854.527:0): avc: denied { add_name } for pid=3455 exe=/bin/bash name=squid.out scontext=root:system_r:initrc_t tcontext=system_u:object_r:squid_log_t tclass=dir
Is the squid init script messing around with the squid data? It'd be preferable if whatever it was doing was builtin squid functionality, so we don't have to allow initrc_t those privilges.
On Mon, 06 Dec 2004 13:19:51 -0500, Colin Walters walters@redhat.com wrote:
On Sun, 2004-12-05 at 09:57 -0800, Tom London wrote:
Is the squid init script messing around with the squid data? It'd be preferable if whatever it was doing was builtin squid functionality, so we don't have to allow initrc_t those privilges.
I agree, but the files (e.g., /var/log/squid/squid.out) seem created in the script.
Here is a line from /etc/init.d/squid: $SQUID -z -F -D >> /var/log/squid/squid.out 2>&1
So the script running as initrc_t is creating the file on the first run, and opening it for output thereafter, no? After that its written by squid_t.
tom
On Mon, 2004-12-06 at 12:24 -0800, Tom London wrote:
On Mon, 06 Dec 2004 13:19:51 -0500, Colin Walters walters@redhat.com wrote:
On Sun, 2004-12-05 at 09:57 -0800, Tom London wrote:
Is the squid init script messing around with the squid data? It'd be preferable if whatever it was doing was builtin squid functionality, so we don't have to allow initrc_t those privilges.
I agree, but the files (e.g., /var/log/squid/squid.out) seem created in the script.
Here is a line from /etc/init.d/squid: $SQUID -z -F -D >> /var/log/squid/squid.out 2>&1
So the script running as initrc_t is creating the file on the first run, and opening it for output thereafter, no? After that its written by squid_t.
Is this just debugging output or something? Or is that actually how squid writes its normal logging information instead of via syslog?
On Mon, 06 Dec 2004 16:07:41 -0500, Colin Walters walters@redhat.com wrote:
Is this just debugging output or something? Or is that actually how squid writes its normal logging information instead of via syslog?
Colin,
I'm not a squid expert, but I suspect that this is there to capture any stdout/stderr from squid.
After changing policy as described, starting and stopping squid produces a squid.out file of zero bytes, owned by root and of type squid_log_t.
/etc/squid/squid.conf refers to /var/log/squid/access.log, /var/log/squid/cache.log, and /var/log/squid/store.log. These seem to be created properly (aka, owned by squid, type squid_log_t)
tom
On Mon, 2004-12-06 at 13:19 -0800, Tom London wrote:
On Mon, 06 Dec 2004 16:07:41 -0500, Colin Walters walters@redhat.com wrote:
Is this just debugging output or something? Or is that actually how squid writes its normal logging information instead of via syslog?
Colin,
I'm not a squid expert, but I suspect that this is there to capture any stdout/stderr from squid.
I'd suggest just removing that from the init script then; in error cases you probably want the output to the terminal anyways, just like how most other daemons work. (Although right now the policy also denies access to the terminal, long term I hope we'll come up with a good general solution for that problem for all daemons).
selinux@lists.fedoraproject.org