Date: Wed, 5 Sep 2001 12:47:16 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <200109051647.f85GlGY44472@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.NEB.3.96L.1010904164045.57474B-100000@fledge.watson.org> References: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> <Pine.NEB.3.96L.1010904164045.57474B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 4 Sep 2001 16:47:42 -0400 (EDT), Robert Watson <rwatson@FreeBSD.ORG> said: > There are a number of situations where it's desirable to authorize based > on the current process, and others based on the current socket credential. I would argue that any file descriptor is, in and of itself, a (somewhat limited form of) credential. Presumably the 4.3BSD developers thought so as well, since they called the file-descriptor-passing mechanism in Unix-domain sockets SCM_RIGHTS and not SCM_PASSFDS or something similar. > Likewise, a concerning scenerio is one where a socket is provided by > a privileged process to an unprivileged process as its stdio on > execve() -- you don't want the child process to be able to > manipulate that socket in undesirable ways. Indeed. My general objection is not to using the caller's credentials -- although I think the whole issue with cached credentials needs to be rethought -- but to the reintroduction of references to `curproc', which I spent a good deal of time several years ago stamping out. > I suppose the more conservative view would be that, with the > exception of "traditional" file operations (read/write/close), all > operations on devices, sockets, et al, should use current process > credentials rather than cached credentials. An alternative model would be to explicitly associate privilege with file descriptors, and provide some mechanism to explicitly downgrade a descriptor's associated privilege. We actually did this: I introduced a socket option which, when set, would clear the SS_PRIV flag on the socket. Eventually this was forgone in favor of a true credential check in the places where SS_PRIV was formerly used. -GAWollman 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?200109051647.f85GlGY44472>