Which approach should be taken for audit subsystem

Pawel Jakub Dawidek nick at garage.freebsd.pl
Fri Apr 11 14:42:42 GMT 2003


On Wed, Apr 09, 2003 at 10:26:07PM -0400, Robert Watson wrote:
+> [...] One of the problems that is
+> frequently stumbled into is that of race conditions on arguments.  Almost
+> all (although not quite all) such modules have problems wherein the
+> arguments are copied into the kernel twice: once by the wrapper, and once
+> by the original kernel service code.  With an SMP box, or even with a
+> single-threaded box if you force page faults, you can race to replace an
+> argument between the check and use, resulting in the wrapper using one
+> version, and the kernel using another.  Neils Provos modified systrace to
+> add a system call argument look-aside buffer when I pointed this
+> vulnerability out to him.  I talk a bit more about this vulnerability and
+> some related vulnerabilities in my DISCEX III paper... 

And how to handle with it?

My idea is:

	USERLAND -> WRAPPER -> KERNEL

When wrapper is running it copies arguments to kernel memory.
Now it could safety operate on arguments and before real syscall is called
arguments are copied to userland to old place or memory is allocated
in userland and arguments are copied to new place. Is this is safe enough?

But there could be a problem with copying arguments to new place, because
if we are using obreak() (this is the simplest and cleanest way) there
could be some limits on memory size that could be allocated by process.

What is your opinion about this?

-- 
Pawel Jakub Dawidek                       pawel at dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/trustedbsd-discuss/attachments/20030411/d9be73a2/attachment.bin


More information about the trustedbsd-discuss mailing list