9:11 a.m.
Hi,
I have a Linux system running a 2.6.5 kernel, which cannot be upgraded to a later
release for the time being. I do have the source available, and can patch it if
necessary.
I wish to run some kind of system call level auditing/logging for security purposes. I
have
the LaUS package installed with the PAM modules, but this does not impliment the system
call level logging that I require, without a patch. The trouble is that the only
patches that I can
find are not compatible with this particular kernel.
Looking at other options, it appears that syscalltrace is no longer being developed ?.
It doesn't appear for the 2.6 kernels, and LSM again looks only good to 2.5 kernels.
The only other thing that I can find is ptrace, but has to be explicity run under each
executable ?.
What are my options here ?.
Thanks in advance,
Adrian.
9:38 a.m.
On Sunday 07 May 2006 10:11, Adrian Powell wrote:
I have a Linux system running a 2.6.5 kernel, which cannot be
upgraded to a later release for the time being.
Hi,
I think the native linux audit system landed in the 2.6.6 kernel. I think
2.6.14 was the kernel where we finally had things working pretty good for
syscall auditing.
I do have the source available, and can patch it if necessary. I wish
to run
some kind of system call level auditing/logging for security purposes.
I think you will likely have to do quite a bit of work. You can copy
kernel/audit.c and kernel/auditsc.c to your old kernel as well as
include/linux/audit.h. The problem is going to be adding all the hook
functions to the right place.
I have the LaUS package installed with the PAM modules, but this does
not
impliment the system call level logging that I require, without a patch.
LaUS is a different and incompatible audit system. The userspace piece that
you would want is the audit-1.0.14 package. There is a lot of patching of
trusted apps, though.
The trouble is that the only patches that I can find are not
compatible with
this particular kernel.
Same with porting the native linux audit system. You would have to do quiet a
bit of sleuthinging around to place all the hooks in the right place. The
native audit system also depends quite a bit on netlink, which has been
changed a few times during 2.6 lifetime. So, you may run into problems with
that, too.
What are my options here ?.
I think your options includes a fair amount of porting of something. Its
either step up to newer kernel or do backporting.
-Steve
9:46 a.m.
Steve,
Thanks for the information. If we were able to go for a 2.6.14
kernel at
some point in the future, would you be fairly confident that this syscall
auditing
code would be maintained in the forseeable future ?. It appears that many
of the earlier developers have now moved on to other things from what I can
find.
Who is regarded as the definitive developer of this code these days ?.
Adrian.
----- Original Message -----
From: "Steve Grubb" <sgrubb(a)redhat.com>
To: <linux-audit(a)redhat.com>
Cc: "Adrian Powell" <awp(a)cray.com>
Sent: Monday, May 08, 2006 3:38 PM
Subject: Re: Linux audit newbie question (Sorry probably a little boring...)
On Sunday 07 May 2006 10:11, Adrian Powell wrote:
> I have a Linux system running a 2.6.5 kernel, which cannot be
> upgraded to a later release for the time being.
Hi,
I think the native linux audit system landed in the 2.6.6 kernel. I think
2.6.14 was the kernel where we finally had things working pretty good for
syscall auditing.
> I do have the source available, and can patch it if necessary. I wish to
> run
> some kind of system call level auditing/logging for security purposes.
I think you will likely have to do quite a bit of work. You can copy
kernel/audit.c and kernel/auditsc.c to your old kernel as well as
include/linux/audit.h. The problem is going to be adding all the hook
functions to the right place.
> I have the LaUS package installed with the PAM modules, but this does not
> impliment the system call level logging that I require, without a patch.
LaUS is a different and incompatible audit system. The userspace piece
that
you would want is the audit-1.0.14 package. There is a lot of patching of
trusted apps, though.
> The trouble is that the only patches that I can find are not compatible
> with
> this particular kernel.
Same with porting the native linux audit system. You would have to do
quiet a
bit of sleuthinging around to place all the hooks in the right place. The
native audit system also depends quite a bit on netlink, which has been
changed a few times during 2.6 lifetime. So, you may run into problems
with
that, too.
> What are my options here ?.
I think your options includes a fair amount of porting of something. Its
either step up to newer kernel or do backporting.
-Steve
10:12 a.m.
On Sunday 07 May 2006 10:46, Adrian Powell wrote:
Thanks for the information. If we were able to go for a
2.6.14
kernel at some point in the future, would you be fairly confident that this
syscall auditing code would be maintained in the forseeable future ?.
Yes, it is in the kernel that is distributed by kernel.org. So, it will be
maintained. It is also a main ingrediant for anyone doing CAPP/LSPP
certification. All major distributions and their hardware partners have a
vested interest in doing this, so there should be people to maintain this in
the future.
That said, I don't forsee a lot of maintenance once we are completely done
with it. It is the kind of project that can come to an end and just have
someone watch for changes that may impact the audit system (new syscalls,
changed code paths, etc.)
It appears that many of the earlier developers have now moved on to
other
things from what I can find. Who is regarded as the definitive developer of
this code these days ?.
I am for user space side, there is a bunch of people that have worked on the
kernel side of it. This mail list can be used for any questions or concerns
about the native/upstreamed linux kernel audit system for either user space
or kernel.
-Steve
6802
days inactive
6803
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Adrian Powell -
Steve Grubb