Date: Wed, 4 Apr 2001 20:52:49 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-arch@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <Pine.NEB.3.96L.1010404204116.14983L-100000@fledge.watson.org> In-Reply-To: <200104050038.RAA03316@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Apr 2001, Terry Lambert wrote: > If you "fix" crget(), you will also need to fix crdup(). There are > plenty of places where crdup() is called, not just in the access() > system call, where it is bogusly used to replace _only_ the initial > group of the real GID, leaving the groups of the effective UID active, > falsely yielding access to the file, even if the real UID would have not > have contained the same group list as the effecive UID (gotta love > "security" code). It's arguable that the access() call is correct for the situation in which it is intended to be used: setuid and setgid programs executed as the real user. The reason is that the groups will have not have been modified by the execution of a setuid/setgid program, only the effective uid and gid, which are preserved as the real uid and gid. However, as has been discussed ad nauseum, access() is prone to races in that type of environment, and should be avoided unless the consumer really knows what they are doing. Don't know if you saw the discuss on freebsd-hackers lately, but we've been considering introducing eaccess() and feaccess() which would allow GUI's to correctly render read-only status for files in the file system without (a) opening them (bad for devices and potentially performance) or (b) replicating kernel policy for protections in userland (often impossible). Remember: the UNIX kernel policy and security primitives are quite different from the userland policy and primitives. The userland policy is layered above the kernel policy, and it's arguable that the kernel should not have to know much if anything about the userland policy (if only for layering reasons). For example, the kernel knows about processes with uids, sets of gids, and a special uid 0, which is privileged to modify these (far more complex in reality due to real/saved/... but you get the idea). This contrasts strongly with the userland policy, which involves users and groups, mapped at authentication time (and arbitrary other times) into kernel primitives. Somewhat poorly at that: the kernel policy and primitives are often a poor match for the desired userland administration policy, and reflect a desire for efficiency, not to mention changing needs over time. > My recommendation is to fix the bogosities, like the non-check of the > MALLOC() return, and to leave it the heck alone in the NFS case. I'm not sure I agree: part of the probelm with this use of crget() is that it attempts to arbitrarily create a UNIX user credential without knowledge of what that credential contains. Most credentials (in fact, all, except for that instance, and a similar instance in the ncp code) are inherited from the proc0 ucred, modulo authorized modification in the inheritence path. If you really do want to create a credential here, isn't it an NFS credential you want to arbitrarily create, not a ucred? Today's ucred has uidinfo, jail pointer, and shortly, capability state, MAC label, etc. The NFS code should not be expected to understand that: if it requires the use of a common credential, presumably it should use an arbitrary NFS credential, which the NFS code is safe assuming both the syntax and semantics of. Shared caching on a multi-user machine has always had interesting security problems associated with it: consider the case of AFS or Coda, where there's a joint cache manager handling a series of seperately authentication connections to the file server. Really, the caches should be isolated, and the processes should see namespaces determined by their credentials permitting them access to the cache. In practice, this is not done, but as a result, it's possible to apply a variety of cache-stuffing attacks. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010404204116.14983L-100000>