From owner-freebsd-security Wed Sep 5 1: 1:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A733B37B408; Wed, 5 Sep 2001 01:01:12 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8580sn07926; Wed, 5 Sep 2001 11:00:54 +0300 (EEST) (envelope-from ru) Date: Wed, 5 Sep 2001 11:00:53 +0300 From: Ruslan Ermilov To: Robert Watson Cc: Garrett Wollman , net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <20010905110053.G96906@sunbay.com> References: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Tue, Sep 04, 2001 at 04:47:42PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Sep 04, 2001 at 04:47:42PM -0400, Robert Watson wrote: > > On Thu, 30 Aug 2001, Garrett Wollman wrote: > > > < 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. > Definitely, we don't want it this way! > 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. > OpenBSD and NetBSD both authorize based on the curproc's privileges. Should I commit this? Index: rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.56 diff -u -p -r1.56 rtsock.c --- rtsock.c 2001/08/31 12:31:09 1.56 +++ rtsock.c 2001/09/05 07:58:47 @@ -331,8 +331,8 @@ route_output(m, so) * Verify that the caller has the appropriate privilege; RTM_GET * is the only operation the non-superuser is allowed. */ - if (rtm->rtm_type != RTM_GET && suser_xxx(so->so_cred, NULL, 0) != 0) - senderr(EPERM); + if (rtm->rtm_type != RTM_GET && (error = suser(curproc)) != 0) + senderr(error); switch (rtm->rtm_type) { Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message