On Tue, 2013-05-28 at 11:59 +0200, Geert Janssens wrote:
> On Tuesday 28 May 2013 11:28:06 Dominick Grift wrote:
> > On Tue, 2013-05-28 at 10:26 +0200, Geert Janssens wrote:
> > > type=AVC msg=audit(1369468867.049:94733): avc: denied { search } for
> > > pid=7230 comm="awstats.pl" name="www" dev=xvda ino=5832775
> > > scontext=system_u:system_r:awstats_t:s0-s0:c0.c1023
> > > tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
> > >
> > > Next I'm confused with the labels. The file is labeled
> > > system_u:object_r:httpd_log_t:s0, but the avc seems to complain about
> > > system_u:object_r:httpd_sys_content_t:s0
> > The awstats.pl command was trying to "traverse" the "(/var/)www"
> > directory, which is labeled rightfully httpd_sys_content_t.
> >
> > I can get all that information (and more) by analyzing the "type=AVC"
> > line above.
> >
> > Either you have "misconfigured" awstats (what business does awstats.pl
> > have with webserver content?) or you need to adjust the policy to
> > reflect your particular configuration
>
> Thanks for spelling out the AVC for me. But what exactly does "traverse" mean in this context
> ? Does it simply mean that awstats is trying to access a file somewhere in the tree below
> /var/www ? Or is it trying to read the contents of /var/www directly for some reason ?
>
The former. (trying to get to a object below /var/www. search means "to
traverse". if awstats.pl would list the www directory then you would see
"read" or "dir" instead of "search" on "dir"
> This particular server is hosting websites for multiple clients. Each client has access (via ftps)
> to a subdirectory somewhere in /var/www. They can use this access to manage their websites.
> In addition, to give each client access to the weblogs for his/her own website, we had decided
> to write logs per website to a log directory inside the client's hosting space. This directory is
> only accessible via ftps, not via http.
The question remains: what business does " awstats.pl " have
below /var/www. That needs to be determined. Then we can determine
whether the file(s)that awstats.pl is trying to get to, should be there
in the first place. For example: its usually not a good idea to store
logs in a webroot.
>
> And that's why awstats needs access to /var/www. With the latest security updates something
> must have changed, because this configuration worked before I applied them.
That may well be yes
>
> But regardless of what worked before, what would you suggest as a solution for my situation ?
It really depends on what awstats.pl is trying to do there. But you can
always go for the easy route and use audit2allow to allow awstats
whatever its trying to do there.
>
> Geert
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
