From owner-freebsd-net Wed Sep 5 9:47:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B6A4937B405; Wed, 5 Sep 2001 09:47:17 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f85GlGY44472; Wed, 5 Sep 2001 12:47:16 -0400 (EDT) (envelope-from wollman) Date: Wed, 5 Sep 2001 12:47:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200109051647.f85GlGY44472@khavrinen.lcs.mit.edu> To: Robert Watson Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser In-Reply-To: References: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: 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-net" in the body of the message