Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Jul 1998 03:08:52 -0400
From:      "Allen Smith" <easmith@beatrice.rutgers.edu>
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
Message-ID:  <9807010308.ZM11585@beatrice.rutgers.edu>
In-Reply-To: David Greenman <dg@root.com>    "Re: bsd securelevel patch question" (Jun 24,  8:49pm)
References:  <199806250349.UAA08929@implode.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9807010308.ZM11585>