From owner-freebsd-arch Sat Sep 2 14:51:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7EB5537B43F for ; Sat, 2 Sep 2000 14:51:49 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA60872; Sat, 2 Sep 2000 17:51:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 2 Sep 2000 17:51:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxime Henrion Cc: freebsd-arch@freebsd.org Subject: Re: thought about allocation of the first 1024th ports In-Reply-To: <20000902180027.A13029@cybercable.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In most cases, inetd is used to provide the type of service you describe. Inetd is capable of binding privileged ports, and then spawning service applications with specific sets of rights to receive the appropriate socket connections. For example, fingerd does not run with privilege under FreeBSD, rather as "nobody", which is configured in /etc/inetd.conf. Currently, for applications that cannot/do not use inetd (for example, applications with complex access control of their own, or performance requirements that can't be met with inetd), privilege is required, or a privileged helper is required. Even using today's mechanisms, you could imagine a socketsd running, which accepts unix domain socket connections passing a request for a specific type of socket to be bound. Using passed credentials, the daemon could verify the identity of the calling process, and then perform an authorization check. Using file descriptor passing on the UNIX domain socket, the privileged socket can be returned without delegating the binding privilege itself. This can be used for other forms of privileged activity -- the CMU cyrus server makes use of a privileged authentication daemon to perform password checks, rather than holding the privilege itself, reducing risk. You mention, in a follow-up e-mail, that capabilities are an option for addressing this. Yes, that is true, and you can find a capabilities implementation for FreeBSD on www.trustedbsd.org. If you use a -CURRENT of the last week or so, yop'll have to wait for me to put 0.5 of the patch online tonight. However, all CAP_NET_BIND does is violate the system protection policy against binding low port numbers without super-user privilege. This is not the same as fine-grained access control -- what it seems like you'd like is a way to bind new DAC-like access control requirements to specific port numbers. For example, a sysctl modifying an ACL in-kernel for each port number. I've considered such mechanisms, and even experimentally implemented them, but I think the real answer is a more general access control system. I'll describe the initial design for one at BSDcon in October, although the implementation is quite a ways away. In the mean time, use inetd where possible, otherwise use a secure privileged helper process of some sort, or be very careful when giving up privilege to get it right :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message