On Thu, Apr 08, 2010 at 04:08:46PM +0100, Arthur Dent wrote:
On Thu, 2010-04-08 at 16:41 +0200, Dominick Grift wrote:
Having done all that (including moving mlogc back to /var/log/mlogc) these are the current AVCs (18 of them) since making the above
changes:
# ausearch -m AVC -ts recent | audit2allow -R
require { type var_log_t; type httpd_log_t; type pcscd_t; type httpd_t; type mlogc_t; class capability dac_override; class unix_stream_socket connectto; class sem { read write unix_write }; class file { write rename unlink }; class dir create; }
#============= httpd_t ============== allow httpd_t httpd_log_t:file write; allow httpd_t var_log_t:dir create;
As for above. Make sure that file in question is labelled properly.
Again httpd_t should not need to write to its log files. Neither should mod_security. I also have mod_security running on a server and it does not need to
write to log files (only append)
So we may end up silencing that denial.
As for httpd_t creating a dir in /var/log: I would like to see the
denial. I was expecting mlogc to create
/var/log/mlogc.
I think it's this one:
node=troodos.org.uk type=AVC msg=audit(1270732811.767:47066): avc: denied { create } for pid=10875 comm="httpd" name="20100408" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir node=troodos.org.uk type=SYSCALL msg=audit(1270732811.767:47066): arch=40000003 syscall=39 success=yes exit=0 a0=2d01a70 a1=1e8 a2=84a1e4 a3=2 items=0 ppid=10852 pid=10875 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
But if that's related to a labelling issue I just done a restorecon on /var/log/ and I got a ton of these:
# restorecon -Rv /var/log/ restorecon reset /var/log/mlogc context unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 restorecon reset /var/log/mlogc/data context unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 restorecon reset /var/log/mlogc/data/20100321 context unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 ... Hundreds more restorecon reset /var/log/mlogc/data/20100326/20100326-1322 context unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 restorecon reset /var/log/mlogc/mlogc-error.log context system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 restorecon reset /var/log/mlogc/mlogc-transaction.log context system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0 restorecon reset /var/log/fail2ban.log.1 context system_u:object_r:fail2ban_log_t:s0->system_u:object_r:var_log_t:s0
When I switched back to /var/log/ I forgot to redo the restorecon. Sorry. Is that the reason?
May well be , yes . see if you can reproduce. also restorecon /etc/mlogc.conf
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux