Date: Sat, 2 Sep 2000 17:51:35 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Maxime Henrion <mux@qualys.com> Cc: freebsd-arch@freebsd.org Subject: Re: thought about allocation of the first 1024th ports Message-ID: <Pine.NEB.3.96L.1000902174559.60028D-100000@fledge.watson.org> In-Reply-To: <20000902180027.A13029@cybercable.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000902174559.60028D-100000>