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
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
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
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
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org