From: Klaus Weidner <klaus@atsec.com>
To: Clif Flynt <clif@cflynt.com>
Cc: linux-audit@redhat.com
Subject: Re: SuSE 10.1 and linux audit
Date: Fri, 11 Aug 2006 11:44:51 -0500 [thread overview]
Message-ID: <20060811164451.GE5964@w-m-p.com> (raw)
In-Reply-To: <20060811162511.GA30404@clif.cflynt.com>
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-kernheaders-3.0-45.3.src.rpm
>
> 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
prev parent reply other threads:[~2006-08-11 16:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-11 16:25 SuSE 10.1 and linux audit Clif Flynt
2006-08-11 16:44 ` Klaus Weidner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060811164451.GE5964@w-m-p.com \
--to=klaus@atsec.com \
--cc=clif@cflynt.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.