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?
Attachment:
signature.asc
Description: This is a digitally signed message part
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
