Awstats search access denied

[Geert Janssens]

Hi,

I have updated my Centos 6 installation a couple of days ago to include the most recent 
packages.

Since that moment my awstats cron job is not working anymore. This cron job reads apache 
log files and generates statistics for this.

Here is a sample of the avc I get:
----
time->Sat May 25 10:01:07 2013
type=PATH msg=audit(1369468867.049:94733): item=1 name=(null) inode=5832775 
dev=ca:00 mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:httpd_sys_content_t:s0
type=PATH msg=audit(1369468867.049:94733): item=0 
name="/var/www/hosting/iyoga.be/log/access_log"
type=CWD msg=audit(1369468867.049:94733):  cwd="/"
type=SYSCALL msg=audit(1369468867.049:94733): arch=c000003e syscall=2 success=no 
exit=-13 a0=2cc6490 a1=0 a2=1b6 a3=37b751dd40 items=2 ppid=7229 pid=7230 auid=0 
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2826 
comm="awstats.pl" exe="/usr/bin/perl"
subj=system_u:system_r:awstats_t:s0-s0:c0.c1023 
key=(null)
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
----

In /var/log/messages the corresponding message is:
May 25 10:01:12 abmpub6 setroubleshoot: SELinux is preventing /usr/bin/perl from search 
access on the directory /var/www/hosting/iyoga.be/log/access_log. For complete SELinux 
messages.
run sealert -l cb05aa4b-3270-49e5-be6f-37c8a6cadc56

The first oddity to note is that /var/www/hosting/iyoga.be/log/access_log is not a
directory, 
but a file.

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

Currently installed packages:
selinux-policy-targeted-3.7.19-195.el6_4.5.noarch
awstats-7.0-3.el6.noarch

I have no idea what happens here, let alone how to fix it. Can anyone shed some more light

on this ?

Thank you,

Geert

[Dominick Grift]

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

[Geert Janssens]

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 ?

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.

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.

But regardless of what worked before, what would you suggest as a solution for my
situation ?

Geert

[Dominick Grift]

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

[Manuel Wolfshant]

On 05/28/2013 02:11 PM, Dominick Grift wrote:
>  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 
It's trying to reach
and parse the logs

[Dominick Grift]

On Tue, 2013-05-28 at 15:14 +0300, Manuel Wolfshant wrote:
>  On 05/28/2013 02:11 PM, Dominick Grift wrote:
>  > 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
>  It's trying to reach and parse the logs 
Why are those logs there and why are they labeled type httpd_log_t?

Anyways either you allow it using audit2allow or you find a more
suitable location and type for these log files

>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux