Hello, after update from FC2 to FC3 and enabled SELinux with:
1. Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname. 2. To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling. 3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel. 4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change. 5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy.
and at step 5 I have entry with the avc: denied messages. This have i found: Mar 9 13:19:00 homer kernel: audit(1110370740.023:0): avc: denied { unlink } for pid=5797 exe=/usr/sbin/httpd name=ssl_mutex.5797 dev=hda1 ino=1063633 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_log_t tclass=file Mar 9 13:19:00 homer httpd: Starten von httpd succeeded Mar 9 13:19:01 homer kernel: audit(1110370741.003:0): avc: denied { getattr } for pid=5798 exe=/usr/sbin/httpd path=/etc/php.ini dev=hda1 ino=246465 scontext=root:system_r:httpd_t tcontext=system_u:object_r:etc_t tclass=lnk_file
what must I do to correct this??
Hans Müller wrote:
Hello, after update from FC2 to FC3 and enabled SELinux with:
- Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname.
- To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux
will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling. 3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel. 4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change. 5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy.
and at step 5 I have entry with the avc: denied messages. This have i found: Mar 9 13:19:00 homer kernel: audit(1110370740.023:0): avc: denied { unlink } for pid=5797 exe=/usr/sbin/httpd name=ssl_mutex.5797 dev=hda1 ino=1063633 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_log_t tclass=file
Is there a way to get these files creates somewhere else? We might need to change policy, but allowing httpd the ability to unlink log files is not an option. Since this would allow a cracker to cleanup his tracks.
Mar 9 13:19:00 homer httpd: Starten von httpd succeeded Mar 9 13:19:01 homer kernel: audit(1110370741.003:0): avc: denied { getattr } for pid=5798 exe=/usr/sbin/httpd path=/etc/php.ini dev=hda1 ino=246465 scontext=root:system_r:httpd_t tcontext=system_u:object_r:etc_t tclass=lnk_file
Why is /etc/php.ini a link file?
what must I do to correct this??
Why is /etc/php.ini a link file?
It is a link file because i have installed then Zend Optimizer.
and at step 5 I have entry with the avc: denied messages. This have i found: Mar 9 13:19:00 homer kernel: audit(1110370740.023:0): avc: denied { unlink } for pid=5797 exe=/usr/sbin/httpd name=ssl_mutex.5797 dev=hda1 ino=1063633 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_log_t tclass=file
Is there a way to get these files creates somewhere else? We might need to change policy, but allowing httpd the ability to unlink log files is not an option. Since this would allow a cracker to cleanup his tracks.
I think no. The logfiles the since FC2 can it be that a have to do something with the logfiles??
Hans Müller wrote:
Why is /etc/php.ini a link file?
It is a link file because i have installed then Zend Optimizer.
Ok I will add the privs to do this.
and at step 5 I have entry with the avc: denied messages. This have i found: Mar 9 13:19:00 homer kernel: audit(1110370740.023:0): avc: denied { unlink } for pid=5797 exe=/usr/sbin/httpd name=ssl_mutex.5797 dev=hda1 ino=1063633 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_log_t tclass=file
Is there a way to get these files creates somewhere else? We might need to change policy, but allowing httpd the ability to unlink log files is not an option. Since this would allow a cracker to cleanup his tracks.
I think no. The logfiles the since FC2 can it be that a have to do something with the logfiles??
No the problem is the mutex files. You could clean those up in the init scripts but the problem is, httpd is creating those files in /etc/httpd/logs directory, which gives them a file context of httpd_log_t which is the same as the log files. So in order to delete them, httpd needs the ability to delete httpd_log_t, which would allow it to delete its log files.
Ok the first problem(with the php.ini) will be solved with an update. Right? And what must I do exactly with the second problem?
Thanks for your help.
On Wed, 09 Mar 2005 18:15:34 +0100, Hans Müller ndof@gmx.li wrote:
Ok the first problem(with the php.ini) will be solved with an update. Right? And what must I do exactly with the second problem?
file a bug report possibly
Rahul Sundaram wrote:
On Wed, 09 Mar 2005 18:15:34 +0100, Hans Müller ndof@gmx.li wrote:
Ok the first problem(with the php.ini) will be solved with an update. Right? And what must I do exactly with the second problem?
file a bug report possibly
Yes file a bug that httpd should not be creating mutex files in the log directory.
Not being able to delete them is not going to probably be a problem, other than cluttering up the disk. You could add something to the startup script to remove them.
Dan
-
Daniel J Walsh -
Hans Müller -
Rahul Sundaram