selinux not writing any log files
We're running redhat and selinux. We have enforcing turned on. For some strange reason nothing is getting written to any of my http log files and more disconcerting is that nothing is getting written to the /var/log/audit log files so I could figure out what is going on.
Here are the file contexts:
drwxr-x---. root root system_u:object_r:auditd_l
drwxrwx---. webadmin apache unconfined_u:object_r:http
I've run restorecon on the audit folder and that didn't seem to do anything.
If we setenforce to 0, we still don't get any log files (audit and httpd) written. We have about 20 different domains on the go so it's unlikely that we've messed up every single one of them. Also I know that the individual log file directories are correct because if I delete one of them and then restart the web server it fails because it can't find the directory.
Not sure where to go next with this
Here are the file contexts:
drwxr-x---. root root system_u:object_r:auditd_l
drwxrwx---. webadmin apache unconfined_u:object_r:http
I've run restorecon on the audit folder and that didn't seem to do anything.
If we setenforce to 0, we still don't get any log files (audit and httpd) written. We have about 20 different domains on the go so it's unlikely that we've messed up every single one of them. Also I know that the individual log file directories are correct because if I delete one of them and then restart the web server it fails because it can't find the directory.
Not sure where to go next with this
Make sure you have syslog or rsyslog installed and running.
This is the process that writes into those files.
If syslog is running, look at /etc/syslog.conf or /etc/rsyslog.conf.
That you are not voiding the events
See if you have an audit file reference.
Maybe you have a centralized syslog server to which all systems forward their events.
This is the process that writes into those files.
If syslog is running, look at /etc/syslog.conf or /etc/rsyslog.conf.
That you are not voiding the events
See if you have an audit file reference.
Maybe you have a centralized syslog server to which all systems forward their events.
ASKER
I feel like I'm on an episode of the twilight zone. When I came in this morning the audit file was 0 length like it has been for a couple of weeks. I've turned enforcing on and off several times today testing out various things. Now it has tons of entries and enforcing is turned on.
Even some of the web logs now have entries. One thing that did happen this morning was a logrotate. Is there something in syslog or apache that decides when to write the log files out to disk? I still have several web sites that have empty logs, but it might be caching or something specific to them.
Even some of the web logs now have entries. One thing that did happen this morning was a logrotate. Is there something in syslog or apache that decides when to write the log files out to disk? I still have several web sites that have empty logs, but it might be caching or something specific to them.
Logrotate script supposed to issue a reload to syslog so t reattached to the newly created files
I think apache might not need, but sometimes a reload is issued to it so it defaces from the old and attaches to the new logs
I think apache might not need, but sometimes a reload is issued to it so it defaces from the old and attaches to the new logs
It shouldnt have `cached` that much information I think the issue was either a process not running all of a sudden it just had something to log.
How long has the server been up??
How long has the server been up??
ASKER
It's a brand new server, been in service for approx. 4 months. Server is rebooted about every two weeks.
I've restarted apache, it failed the first time with a log file that it didn't have access to. I looked at the context info and it appeared to be correct. I reset the context anyways, started the web server and finally everything seems to be working. I think that apache might not like having the enforcing turned off and on while it's running.
In any event thanks for your help, but we seem to be up and running.
I've restarted apache, it failed the first time with a log file that it didn't have access to. I looked at the context info and it appeared to be correct. I reset the context anyways, started the web server and finally everything seems to be working. I think that apache might not like having the enforcing turned off and on while it's running.
In any event thanks for your help, but we seem to be up and running.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm running Redhat release 6.3 I see I'm having a problem with pam_abl and sshd
When I run audit2allow I get the command which I need in order to fix the problem.
allow sshd_t default_t:file read;
So I think I have two choices here. Either I figure out the file types that sshd can read and set pam_abl.conf to that context, or add this command to the policy.
I think I like the first choice, but reading through the sshd_selinux man page doesn't give me any obvious clues as to what that context it might be. Is there somewhere I can see what file types sshd is allowed to read?
When I run audit2allow I get the command which I need in order to fix the problem.
allow sshd_t default_t:file read;
So I think I have two choices here. Either I figure out the file types that sshd can read and set pam_abl.conf to that context, or add this command to the policy.
I think I like the first choice, but reading through the sshd_selinux man page doesn't give me any obvious clues as to what that context it might be. Is there somewhere I can see what file types sshd is allowed to read?
ASKER
Seems to have been a configuration problem, which has been resolved. I forgot to close this out, and now I can't remember what was wrong, other than it was likely a mistake on my part. I appreciate all of the comments, they were helpful.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for geekdad1's comment #a39872104
for the following reason:
The other comments were helpful, but not instructive as a solution. Mine aren't either but this was the only way to close this question out.
Accepted answer: 0 points for geekdad1's comment #a39872104
for the following reason:
The other comments were helpful, but not instructive as a solution. Mine aren't either but this was the only way to close this question out.
Usually you accept helpful comments or shed some light on radically opposite solution.
ASKER
Sorry, I understand that awarding points should have been done, but when I read through the comments and most of them were questions trying to help me figure out where the problem might be. I thought that picking one of those as the solution would have been confusing to anyone looking at the problem thread later on, since it did not lead to a solution.
Are you expecting anything to be logged?
What happens if you tail -f the audit file and then setenforce 0 and then setenforce 1?