On Fri, Aug 11, 2006 at 12:25:11PM -0400, Clif Flynt wrote:
8) Install the new kernel headers. I got these from:
http://rpm.pbone.net/index.php3/stat/26/dist/0/size/728548/name/glibc-ker...
I extracted the tar bz2 file with rpm2cpio, and then untarred
that file to install the headers.
This is one step that I think is very suspect. I'm not sure where these
headers are referenced, and which code is using what.
Instead of doing that, you could unpack the headers to a separate
location, and provide that directory as an additional include path (using
-I) when compiling the audit tools.
It'll probably also work to completely skip the glibc-kernheaders, and
add the include/linux and include/asm directories from your kernel source
tree to the include path when compiling auditd.
I've tried building the 2.6.17 kernel with both the original
headers
and the new ones and seen no difference in behavior, but I might have
just not done a test that would exercise the trouble spots.
Building the kernel does not reference glibc-kernheaders, those are only
used for compiling userspace apps that need to know about kernel data
structures.
This is another thing that I think is suspect. Can a halt
be aborted once it's reached the K15auditd stage of shutdown?
If so, this is a security hole that would allow an unprivileged
user to disable auditing, if not, then it should be fine.
If your untrusted users have enough privileges to shut down your system,
I think stopping auditd is the least of your worries...
13) create /etc/audit and copy /etc/auditd.conf and audit.rules
to it. Again, I think this step could be avoided by proper
use of various compile time flags, but this works.
It would probably be better to use symlinks instead of copies to avoid
having multiple versions of the files on the system. You could also do
ln -s /etc /etc/audit
to create a symlink pointing from /etc/audit/ back to /etc/ to keep the
apps happy if they don't agree about the location.
-Klaus