From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Linux-audit Digest, Vol 27, Issue 2 Date: Mon, 11 Dec 2006 18:03:20 -0500 Message-ID: <200612111803.20251.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Wieprecht, Karen M." Cc: linux-audit@redhat.com, "Thomas, Daniel J." List-Id: linux-audit@redhat.com 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= .=20 >>From a commandline point of view, they are nearly identical. The develop= ment=20 process has a lot of co-development between kernel and user space. When I= 've=20 found something useful that people using 1.0.X series might like to have,= I=20 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=3D-13 (supposed to > catch all failed file accesses) This catches all syscalls that fail with exit code -13. > /etc/sysconfig/auditd > > AUDITD_DISABLE_CONTEXTS=3D"no" (supposed to > allow system to do syscall logging so that the above audit.rules settin= g > will work) This doesn't exist. I don't have any idea where you would have got this f= rom. > 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 r= eturn=20 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 mi= ght > 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 ca= n use=20 syscall auditing of the open syscall with devmajor and devminor to limit = the=20 number of hits. On RHEL4, syscall auditing impacts performance since each= =20 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 m= y > 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=20 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 w= e > 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 cha= nge=20 when the file is being edited, a more general way was created, but at its= =20 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 nee= d.=20 (The line about AUDITD_DISABLE_CONTEXTS doesn't exist in any of the code = I've=20 written.) But you might want to figure out how to limit what you are gett= ing=20 exit code -13's on. I'd think about limiting by syscall and devmajor/mino= r=20 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. T= he=20 EXTRAOPTIONS is what's passed to the audit daemon and it only has foregro= und=20 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 kern= el=20 changes. Audit in 2.6.16 is different than in 2.6.19. Protocols change an= d=20 evolve. Userspace changes too. The 1.2 series of audit is not binary=20 compatible with RHEL4 apps. > then what's the scoop on using Fedora Core (or some other flavor) src r= pms > on RHEL4 if we can't find a RHEL4-specific src rpm for something we nee= d > (like a newer kernel-headers)?=20 I think this is untested and unsupportable. The RHEL4 stream is tested=20 together and can only be guaranteed when packages from its stream are use= d. > 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= .=20 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 on= ly=20 want to install via rpm so that you can roll changes back or figure out w= hat=20 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