5:03 p.m.
On Monday 11 December 2006 15:32, Wieprecht, Karen M. wrote:
1. Audit Version Differences
-------------------------------
- Our SuSE colleague is using the audit 1.2.3
- Our RHEL4 system had audit 1.0.14
If that is correct, then where might I find more on these differences?
In terms of how they do things, there is a lot of difference between them.
From a commandline point of view, they are nearly identical. The
development
process has a lot of co-development between kernel and user space. When
I've
found something useful that people using 1.0.X series might like to have, I
backport it. I do the same for any bugs I know of.
2. Configuration recommendations:
---------------------------------
/etc/audit.rules
-a exit,always -S all -F exit=-13 (supposed to
catch all failed file accesses)
This catches all syscalls that fail with exit code -13.
/etc/sysconfig/auditd
AUDITD_DISABLE_CONTEXTS="no" (supposed to
allow system to do syscall logging so that the above audit.rules setting
will work)
This doesn't exist. I don't have any idea where you would have got this from.
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.
It should have. You would also want to strace the program to verify the return
code. But that would be a bug if it didn't work.
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
This detects changes to the directory inodes
b. -w /etc/nsswitch.conf
This detects changes to the file's inodes
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,
It only logs changes to that directory's inodes.
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...
If you have all the files that you want to watch on one partition, you can use
syscall auditing of the open syscall with devmajor and devminor to limit the
number of hits. On RHEL4, syscall auditing impacts performance since each
rule gets evaluated for every syscall, but watches do not.
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,
You'll probably be overwhelmed with stuff you didn't want also. And this could
consume quite a bit of diskspace.
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.
No, the basic mechanism at work is inode auditing. Because inodes can change
when the file is being edited, a more general way was created, but at its
heart is the inode. Watches hide that from you.
-----------------------
Questions and confusion
-----------------------
1. Should we be able to collect -13 exit codes in RHEL4's audit 1.0.14 ?
Yes.
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 all you want is exit codes of -13, the audit rule above is all you need.
(The line about AUDITD_DISABLE_CONTEXTS doesn't exist in any of the code I've
written.) But you might want to figure out how to limit what you are getting
exit code -13's on. I'd think about limiting by syscall and devmajor/minor
for performance and diskspace reasons.
2. Where might I find out more about the configurable options
accepted
by /etc/sysconfig/auditd?
There are only 3 options and they are documented in the sysconfig file. The
EXTRAOPTIONS is what's passed to the audit daemon and it only has foreground
mode - which is used for debug. So that option would not get used much.
a search on "AUDITD_DISABLE_CONTEXTS" didn't really get
me anywhere ...
Doesn't exist...unless somebody has code they aren't sharing.
3. If a linux kernel is a Linux kernel,
They aren't. Sometimes, userspace and kernels go together because of kernel
changes. Audit in 2.6.16 is different than in 2.6.19. Protocols change and
evolve. Userspace changes too. The 1.2 series of audit is not binary
compatible with RHEL4 apps.
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)?
I think this is untested and unsupportable. The RHEL4 stream is tested
together and can only be guaranteed when packages from its stream are used.
Is this a typical practice, or possible but unsupported, or
completely not
recommended?
In terms of audit, there is more hidden problems than you want to work on.
1.0.14 should do what you need.
4. If there is no src rpm for something we need, but there IS a
tar.gz,
You can make and build anything you want. But as a system admin, you'd only
want to install via rpm so that you can roll changes back or figure out what
package owns each file. You'd never want to do "make install".
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?
Generally, there be dragons ahead. More than I can write about today.
-Steve