Date: Fri, 9 Jul 1999 10:27:25 -0600 From: Nate Williams <nate@mt.sri.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Nate Williams <nate@mt.sri.com>, Robert Watson <robert+freebsd@cyrus.watson.org>, Darren Reed <avalon@coombs.anu.edu.au>, Ben Gras <ben@nl.euro.net>, freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? Message-ID: <199907091627.KAA06672@mt.sri.com> In-Reply-To: <199907091620.MAA16574@khavrinen.lcs.mit.edu> References: <199907081645.KAA29163@mt.sri.com> <Pine.BSF.3.96.990709034644.24202B-100000@fledge.watson.org> <199907091609.KAA06341@mt.sri.com> <199907091620.MAA16574@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907091627.KAA06672>