Date: Wed, 5 Sep 2001 11:00:53 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, 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> In-Reply-To: <Pine.NEB.3.96L.1010904164045.57474B-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Tue, Sep 04, 2001 at 04:47:42PM -0400 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, Sep 04, 2001 at 04:47:42PM -0400, Robert Watson wrote:
>
> 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.
>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010905110053.G96906>