Re: Linux Trace Toolkit for kernel auditing (and thoughts)

[cybertech@cybertech.org]

I don't see it as off topic either, frankly

Granted, the appropriateness of something like that in the mainstream 
kernel is arguable.  However, as I 
understand it, the aim of this list is to find kernel problems, and this 
would be a welcome tool for doing so.

In other threads (i've been lurking for 2 days do to time constraints, 
might as well pop it all in here), there 
have been some suggestions regarding starting this audit with the 2.0 
kernel.  While I do realize
there is a significant installed 2.0 base, I believe that 2.2 or 2.4 would 
be a more appropriate starting 
place.  2.4 would be my preference here, however, it's not yet stable 
enough for me to run it on most 
of my machines here, so that makes run-time testing difficult.  It does 
not, however, preclude a good 
old-fashioned code review -- and I firmly believe much can be discovered 
with some nice reading.

A tool I've run across, but haven't yet used, is a run-time bounds 
checking 
patch for GCC.  I don't know about the viability of a kernel built with 
this patch, but it might be 
interesting -- http://web.inter.nl.net/hcc/Haj.Ten.Brugge


David S. Stahl
NayTech Corporation
cybertech@cybertech.org




Bryan Paxton <evil7@bellsouth.net>
Sent by: owner-kernel-audit@nl.linux.org
06/10/2000 09:08 PM

 
        To:     kernel-audit@nl.linux.org
        cc:     (bcc: CyberTech/CTCS)
        Subject:        Re: Linux Trace Toolkit for kernel auditing



On Sat, 10 Jun 2000, you wrote:
> OK, before anyone replies to this and says that I'm way off
> and yadi ... yadi ... yada ... about the fact that kernel audit
> isn't about inserting new stuff in the kernel ... read until
> the end of the message.

I don't think this is far off the subjects of this list at all.
In fact I think it's perfect.
In two ways:

1. inexperienced users to kernel hacking/auditing could use it for obvious
reasons(auditing, double checking, whatever).

2. Experienced users could use it simply to double check their work.

As long as you and I understand that LTT will never make it into the
kernel, and that you're not trying to get it plugged in either, but simply
advocate it so developers who are auditing can plug it into the src code
they're hacking up could use it. Then no way man. You are totally on the
right track IMHO.

Keep up the awesome work.... And this truely is an excellent idea.

--
Bryan Paxton

"How should I know if it works? That's what beta testers are for. I
          only coded it."
 -- Linus Torvalds.




Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/