Date: Fri, 16 Apr 1999 11:41:00 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Bruce Evans <bde@zeta.org.au> Cc: phk@critter.freebsd.dk, freebsd-security@FreeBSD.ORG Subject: Re: POSIX.1E auditing support, an initial pass and some questions Message-ID: <Pine.BSF.3.96.990416113743.16975E-100000@fledge.watson.org> In-Reply-To: <199904160648.QAA06234@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Apr 1999, Bruce Evans wrote: > >>I had suspected (and observed) as much. What is the rational behind > >>having the name lookup pull the pathname into the kernel as opposed to > >>using a copyin in the syscall and passing it in as an argument? > >>Presumably someone, somewhere has to allocate space on the stack, and if > > Space is allocated by zalloc(). Not long ago, space was allocated by > malloc(). The kernel stack may be too small to hold a name of length > MAXPATHLEN. I had wondered about that. > >>it's done in the syscall function then more argument processing is done in > >>one place? This would make at least a bit more available to an auditing > >>layer in the syscall. > > > >I think it is an old thing, conserving kernel memory. Indeed it may > >not make sense today where the vfs-name-cache is so much more efficient. > >Changing it may be a PITA. > > I think it's just centralisation. The pathname is copied in in one place > instead of in 100's of syscall functions. So the problem now is that we need to do different things with these strings in different places for the purpose of context-sensitive auditing. What do you recommend as the best way to get that string back again from namei()? I assume that ktrace just relies on the sequential execution of the syscall and the ordering of the NAMEI entries in the ktrace is really just the order the namei()'s happen to take place in the source. For auditing, we require a well-defined and consistent order, even if sections of the source change order for some reason. Nate has suggested munging ktrace to do what we need; while this is entirely possible, I'd prefer a more deterministic way of specifying the order of the items getting audited for a syscall. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990416113743.16975E-100000>