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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgpYbyyU11ocz.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
