Linux-audit Digest, Vol 27, Issue 2

[Steve Grubb]

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