Date: Tue, 4 Sep 2001 16:47:42 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Ruslan Ermilov <ru@FreeBSD.ORG>, net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <Pine.NEB.3.96L.1010904164045.57474B-100000@fledge.watson.org> In-Reply-To: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Aug 2001, Garrett Wollman wrote: > <<On Thu, 30 Aug 2001 20:41:32 +0300, Ruslan Ermilov <ru@FreeBSD.ORG> said: > > > + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0) > > + senderr(EACCES); > > I'm certain rwatson would object to this. suser_xxx() allows checking > on the basis of credentials rather than a process, so that's what should > be used. In any case, the correct error is EPERM, not EACCES. 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. So far, the only interesting case I know of for using process rather than socket credentials is wrt bind() and connect(), where you want to use the process credential when changing the port/address binding--this permits a privileged process to share a socket bound to a low port with an unprivileged process, and know that the unprivileged process can't rebind it to another low port number, but must use the one provided by the privileged process. 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. Generally, routing sockets aren't passed from process to process, and any process doing so should beware the consequences of poorly defined access control policies. My suspicion is that this class of socket operations should be authorized using the credential of the current process, but I'd be interested to know what (if anything) other operating systems do to address this problem. Cached credentials in open files/sockets/etc introduces a lot of complication to the UNIX-like security model. 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. I'm not sure I'm comfortable with that, since I haven't thought through all the cases, but it seems "safe". 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-net" 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.1010904164045.57474B-100000>