On Mon, Nov 23, 2009 at 12:20:36PM -0700, m.roth(a)5-cent.us 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list