From owner-freebsd-security Fri Jul 9 9:27:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7B91515146 for ; Fri, 9 Jul 1999 09:27:39 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA11332; Fri, 9 Jul 1999 10:27:26 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA06672; Fri, 9 Jul 1999 10:27:25 -0600 Date: Fri, 9 Jul 1999 10:27:25 -0600 Message-Id: <199907091627.KAA06672@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Garrett Wollman Cc: Nate Williams , Robert Watson , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907091620.MAA16574@khavrinen.lcs.mit.edu> References: <199907081645.KAA29163@mt.sri.com> <199907091609.KAA06341@mt.sri.com> <199907091620.MAA16574@khavrinen.lcs.mit.edu> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> The problem raised here again, of course, is the copyin of string > >> arguments. > > > Does anyone else have any ideas? > > Add auditing data in struct nameidata, and continue to track the > information inside of namei. Should we bloat the struct to include all of the necessary information? What happens when the kernel generates 'too much' information and the information must be expired from the cache *before* the userland process gets a hold of it. > > I don't think this will work, simply because how do we differentiate > > between different syscall that will eventually be running in parallel in > > the kernel? > > They will be running in different execution contexts (i.e., processes, > at least in the CS-theoretic sense). With the arguments that were given to the MACRO, there was no way to differentiate between different 'processes'. How do you know what 'process' you're in in the FreeBSD kernel. p-curproc only works if you have p, and may not be accurate in an SMP kernel. > > I believe there is a trade-off that allows us to somehow 'reduce' > > creation of records with a simple filtering scheme that should be much > > more effecient than generating records that the benefits are easily > > seen. > > BAF (``Berkeley auditing filter'') Agreed. I've spoken on this subject with my employers about this already in months past, but doing this is non-trivial. But I agree that eventually we should do something like this. Not today though. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message