On Mon, Nov 23, 2009 at 12:20:36PM -0700, m.roth@xxxxxxxxx wrote:
> Apologies if this has been covered a million times; if so, please point me
> to the post or thread that answers this.
>
> selinux has an error-handling problem. It complains (we're running it in
> permissive mode, or it would be real grief):
> host=<hostname> type=AVC msg=audit(1259003353.282:46730): avc: denied {
> write } for pid=27369 comm="LLAWP" path="/var/log/httpd/smagent.log"
> dev=sda3 ino=46107891 scontext=user_u:system_r:httpd_t:s0
> tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
SELinux permissive mode means all access is granted but "would be" denials are logged as if they were denied.
With that said lets look at the denial:
your webapp (or whatever LLAWP is) is trying to write to the smagent.log file that is located in /var/log/httpd/smagent.log.
httpd (apache) and webapps that run with apaches permission are not allowed to "write" to their log files. This is because a compromized apache or webapp could erase its trail from the log file. Apache knows this ans instead of writing, apache opens the log file for "append" which it is allowed (apache and webapp can append to their log file but not write)
The best solution to this problem is to tell the author/maintainer of the webapp to fix his code to open the smagent.log file for append instead of write.
A not so good solution is to label the smagent.log file with a type that apache/ and webapps can write to (remember that the webapp can then also remove entries from the log file) I wouldnt trust that webapp knowing that it opens the log file for writing, as this tells me the author of the code may not be focussing on security or doesnt give security as much attention as it deserves.
chcon -t httpd_sys_content_rw_t /var/log/httpd/smagent.log
setsebool allow_httpd_anon_write on
would allow apache and any webapps that run with apaches privileges to write tothe smagent.log file
This may not work in the long run. if the webapp tries to rotate the log file. (it may write to it but it may not create new log files in that location)
Also the labelling that results from chcon is not persistent. Meaning if you run restorecon /var/log/httpd/smagent.log after the chcon command showed above, the security attributes of the file will be reset to the system wide attribute of the location. The semanage fcontext -a -t httpd_sys_content_rw_t /var/log/httpd/smagent.log command followed by a restorecon /var/log/httpd/smagent.log would solve that issue.
Another option is to permit apache and webapps running with apaches permissions to write to log files. This is not encouraged.
Again its best to just report a bug to the author of the webapp/module that you are running and ask him if he could change the webapp to append only to logfiles instead of writing to them.
Tell him that if the webapp gets cracked, the comprized webapp could wipe it trail. (bad)
hth
>
> host=<hostname> type=SYSCALL msg=audit(1259003353.282:46730):
> arch=c000003e syscall=1 per=400000 success=yes exit=124 a0=15
> a1=2aaaab249000 a2=7c a3=7473657571655273 items=0 ppid=1 pid=27369
> auid=32870 uid=48 gid=0 euid=48 suid=48 fsuid=48 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4473 comm="LLAWP"
> exe="/usr/local/opt/smwa-6qmr5-cr013-rhas30-x86-64/webagent/bin/LLAWP"
> subj=user_u:system_r:httpd_t:s0 key=(null)
>
> Now, running sealert tells me to set httpd_unified to 1. I've done this,
> several times, and no joy, so obviously it is *not* the actual error.
>
> I've also tried restorecon.
>
> So, what's the actual error? I'm really tired of this, on more than one
> server, cluttering my logs....
>
> Thanks in advance.
>
> mark
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Attachment:
pgptEbFsxUr14.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
