From owner-freebsd-security Wed Jul 1 00:10:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08249 for freebsd-security-outgoing; Wed, 1 Jul 1998 00:10:46 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08241 for ; Wed, 1 Jul 1998 00:10:43 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id DAA11586; Wed, 1 Jul 1998 03:08:52 -0400 (EDT) From: "Allen Smith" Message-Id: <9807010308.ZM11585@beatrice.rutgers.edu> Date: Wed, 1 Jul 1998 03:08:52 -0400 In-Reply-To: David Greenman "Re: bsd securelevel patch question" (Jun 24, 8:49pm) References: <199806250349.UAA08929@implode.root.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: dg@root.com, security@FreeBSD.ORG Cc: njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com, easmith@beatrice.rutgers.edu Subject: Re: bsd securelevel patch question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 24, 8:49pm, David Greenman (possibly) wrote: > I can imagine that the list could be on the order of 32 large. What about permissions for below-1024 ports? I really don't want to give an anonymous-only version of ftp the ability to bind to _any_ TCP port, for instance - that largely defeats the purpose of having a non-root program able to bind to such ports (namely limiting extra access). > This is one of the reasons why I don't think that a gid based scheme scales > very well. > You'd have to do a search through the fairly large group set each time you > wanted to check for the capability. Even if we did implement the gid method > externally, I still think that the kernel internal representation would be > best handled by a privilege mask. I can see this reasoning for most privileges... but not for the port ones. Hmm... how about a specific permission for PRIV_TCP, granted to any process with a group between x+1 and x+1023, with the port access granted being port=(group-x)? The same would be for PRIV_UDP. This would admittedly necessitate a group set scan for the group corresponding to the requested port. ucred seems to be a logical place to put a privilege mask. Incidentally, I goofed on my correcting message, with regard to NFS; nosuid is of course for the _client_, and the important one in this case would be an extension of the root translation. -Allen P.S. You were mentioning VAXen before; as it happens, I've been a user on those. Their privilege scheme is something I've had in mind also. -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message