RE: Linux-audit Digest, Vol 27, Issue 2

versions of audit, but don't really say why...so what's up? Steve, I'm working with Dan Thomas, and maybe I can give you the big picture on where we stand. Bear with me, we have been Googling, rtfm'ing, etc. etc. etc., but are still having trouble getting pointed to good sources for some of what we are trying to understand, so here's some of what we've been learning (maybe you can fill in some gaps we've been unable to fill?): --- A colleague who uses SuSE made some recommendations about setting up auditing to collect file access failures (caused by permissions problems, etc). Not sure his settings should work on RHEL4, but here's what he recommended, and the issues we found when trying to use them: 1. Audit Version Differences ------------------------------- - Our SuSE colleague is using the audit 1.2.3 (because his SuSE kernel-headers and glibc kern-headers aren't new enough to allow him to use a newer audit package - Our RHEL4 system had audit 1.0.14 on it when I was testing before I went to class last week, and that could explain why things behave differently for me than for him ... I'm finding it difficult to locate documentation explaining how similar or different the two are ... The email you sent Dan sounds like things get tested in the development path and then get back ported to RHEL4, so it sounds like version numbers are not necessarily a good indicator of how similar or different the two might be. If that is correct, then where might I find more on these differences? 2. Configuration recommendations: --------------------------------- Here are my colleague's SuSE audit configurations which I tested on RHEL4 with audit 1.0.14: /etc/audit.rules -a exit,always -S all -F exit=-13 (supposed to catch all failed file accesses) /etc/sysconfig/auditd AUDITD_DISABLE_CONTEXTS="no" (supposed to allow system to do syscall logging so that the above audit.rules setting will work) I do know that -13 events get generated when a regular user tries to mess around with files they do not have privs to access, but I couldn't get my audit daemon to capture any of the -13 events with these settings. 3. Audit data differences on directory watches .vs. file watches : ------------------------------------------------------------------ Since I couldn't get the syscall settings to work, I tested the following configurations independently: /etc/audit.rules a. -w /etc/ -p w b. -w /etc/nsswitch.conf Then I attempted to do a number of things to /etc/nsswitch.conf as a regular user to see if the auditing would detect it: action attempted general /etc watch specific /etc/nsswitch.conf ---------------- ------------------ --------------------------- touch NO yes rm yes yes mv yes yes chown NO yes chgrp NO yes vi yes yes nedit (no because nedit saw that the file did not have write permission, and opened it read only with no errors) chmod 777 NO yes append (via >>) NO yes replace (via > ) NO yes The generic directory watch isn't going to cut it for us because it misses a lot of things that should get logged, but it's not practical to set a specific watch on every file someone might try to mess with where they don't have permission... When I had the specific watch on /etc/nsswitch.conf, I saw that all of the actions I tested generated a -13 exit code, so I would think that my colleague's audit rule would work for us as a generic way to watch for ANY file permission failures rather than having to set a watch on every single file we want to monitor, so that's what we were working towards. We thought that our attempt to collect the -13 exit codes might be failing because of the difference in our audit version from one where we know this works, and that's why we were trying to test a later version of audit. Perhaps you can lend some insight on some of this? ----------------------- Questions and confusion ----------------------- 1. Should we be able to collect -13 exit codes in RHEL4's audit 1.0.14 ? If so, is there something else we might have to do to get this working other than the two configuration changes mentioned in Item 2 above? If not, what might you recommend? We have looked at the /usr/share/doc/audit-1.0.14/capp.rules for guidance, but it doesn't help much when trying to determine how to catch file access failures without specific watched on every file of interest (which I think isn't very practical or reliable). 2. Where might I find out more about the configurable options accepted by /etc/sysconfig/auditd? A google search on "/etc/sysconfig/auditd" came up with a lot package information, but not much about its configuration options, and a search on "AUDITD_DISABLE_CONTEXTS" didn't really get me anywhere ... 3. If a linux kernel is a Linux kernel, then what's the scoop on using Fedora Core (or some other flavor) src rpms on RHEL4 if we can't find a RHEL4-specific src rpm for something we need (like a newer kernel-headers)? Is this a typical practice, or possible but unsupported, or completely not recommended? 4. If there is no src rpm for something we need, but there IS a tar.gz, what's involved in building and installing that package, and are there precautions we need to take, particularly when it involves things like glibc-kernheaders or kernel-headers? Thanks for any pointers or light you can shed on any of this. Karen Wieprecht