Date: Thu, 15 Jul 1999 10:05:16 -0600 From: Nate Williams <nate@mt.sri.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Nate Williams <nate@mt.sri.com>, freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? Message-ID: <199907151605.KAA02632@mt.sri.com> In-Reply-To: <Pine.BSF.3.96.990715112817.27279D-100000@fledge.watson.org> References: <199907151504.JAA02317@mt.sri.com> <Pine.BSF.3.96.990715112817.27279D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > [ I'm supposed to be on vacation ;( ] > > Then don't read your email, or at least ignore it. :-) I did for awhile, then it started building up. :) > > > > Ahh, I understand now. You are worried about one or the other of > > > > namei/audit copyin being redundant. I misunderstood both you and > > > > Garrett. Would it be possible to copy the string from the namei buffer, > > > > thus avoiding the issue of modifying namei? > > > > > > I haven't looked closely at the namei implementation -- at some point the > > > entire string is dumped into a KTRACE record by namei() > > > > Assuming we use KTRACE, which I though we decided wasn't up to the task > > due to many things. Given that it's not up to it, let's not rely on it > > doing anything, or being reliant on it. > > My point we merely that wherever KTRACE is doing it seems to be a good > place to do it--we definitely want only one copyin, and it really should > be the same copyin as namei() is using, to prevent races where shared > memory is in use on an SMP. Otherwise two processes can deceive the > auditing mechanism: p1 and p2 share a memory segment. p1 invokes chmod() > with a string argument in the shared secment. The kernel, on behalf of > p1, copies in the auditing record from p1. Then p2 modifies the value, > followed by the kernel reading the value in again for the purposes of > namei(). This 'race' exists in SMP already, so there's nothing the kernel can do to stop it anymore than it could today. If two threads were running in parallet (and we had kernel threads implemented), these kinds of problems would have to be dealt with anyway. Where this 'safety' exists in the kernel is mostly irrelevant since the kernel will have to guarantee that the data passed in will be constant and unchanging from the time the system enters the kernel. > I don't really have anything to prove here, except that copying in > arguments is something that has to be done properly to minimize the > chances of races. My issue is that we only want to do the copyin() once (for performance reasons), and secondly to minimize core modifications as much as possible to make it more likely that the changes will be accepted, and finally to make it 'easy' to understand what it going on, to ease long-term maintanence of the code base by future developers. > > Again, since we're already instrumenting the syscall code, let's do it > > all there, and provide some 'generic' stubs that each syscall can do on > > it's own, rather than do the re-direction in the kernel. ... > > Having implemented a number of syscalls like this already, I found the > experience to be quite painful: every possible exit condition from the > syscall needs to have an individual commit with appropriate data, etc. I understand. Terry Lambert would jump in here and state that we need a single entry/exit point. However, he uses goto's all over the place to accomplish this. :( In defense of him (I'm acctually defending him), this kind of modification would make alot of things easier. Most notably, kernel threads are going to benefit from these kind of modifications in any case, so it may be necessary to add single exit points. However, that is not a change I'm willing to make (yet), at least without some support from 'those that can accept/reject kernel changes'. > I agree that ease of understanding is important, but I feel that retaining > code simplicity for syscall implementors is also important. We get a big > stepping stone towards having implemented a lot of syscall auditing just > by putting in record creation and commital outside of the syscall, as we > already have return codes audited, as well as credentials. But, we are missing alot of the necessary information that still needs to be done. And, it adds a lot of complexity to the problem, because we know need to 'build' records made up of sub-records. How many 'partially built' records can we have active at any one time (remember, kernel memory is precious)? Do we pre-allocate records? In essence, we move from a 'record gathering' system to an 'event based' system, where IDS records are created/passed on depending on the events given to them. 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?199907151605.KAA02632>