Linux-audit Digest, Vol 27, Issue 2

[Wieprecht, Karen M.]

>>  What is the real problem though? You mention that you want to change
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