From owner-cvs-all Thu Aug 16 7:15:41 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B3EEC37B407; Thu, 16 Aug 2001 07:15:20 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f7GEESf84371; Thu, 16 Aug 2001 10:14:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 16 Aug 2001 10:14:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: cjclark@alum.mit.edu Cc: David Malone , Mikhail Teterin , alex@big.endian.de, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc inetd.conf In-Reply-To: <20010816000823.H330@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 16 Aug 2001, Crist J. Clark wrote: > > Note that if the same approach is taken as with ftpd, the ability to > > exploit a bug resulting in arbitrary code execution can gain the > > privilege. FTPd sets the effective euid to that of the user, but > > maintains a saved uid so it can switch back to root to bind privileged > > ports. An approach that might be taken is to have a pair of processes > > -- one with privilege, and one without. The one with privilege would > > communicate via IPC with the low privilege process, and grant specific > > requests via file descriptor passing (such as the binding of sockets, > > opening of devices, etc), limiting the scope of a vulnerability in the > > exposed code. This does add substantial complexity, and has to be > > carefully analyzed so as to determine that it won't leak privileges. We > > have an on-going project as part of our DARPA grant to look at generate > > techniques for partitioning applications this way. You can e-mail > > Lee Badger if you're interested -- he's a co-PI on > > the project, and is focusing on the application impact of privilege. > > When are we just going to give up the now rather silly concept of > "privileged ports?" Security on a UNIX platform gets _better_ when > non-root processes can open ports <1024. Since no one (except for a > limited few people on highly controlled, isolated networks) should ever > trust remote machine, using a port <1024 is meaningless to the remote > machine. It's also only an UNIX anachronism, and therefore meaningless > in a heterogeneous environment. > > It would be so-o nice to have a sysctl(8) to turn off privileged ports > and not have to worry about all of these problems with named(8), > syslogd(8), ftpd(8), etc. If I do the work, is anyone going to fight > committing it? -- Crist J. Clark cjclark@alum.mit.edu Note that, although I agree entirely with your observation about the rediculousness and arbitrariness of the model, modifying it without careful consideration could have some pretty bad effects also. They includes: (1) Applications and services that make assumptions about packets sourced from low port numbers. This includes the {rsh,rexec,rlogin,...} class of services, as well as NFS, portmap, and others. This is arguably a problem with those services, but one that has to be resolved rather than breezed over. (2) Ability for un-trusted users to spoof services as being "legitimate". For example, suppose your server hosts un-trusted users (it's a public shell server for an ISP). You require your customers to use SSH to log in, and have disabled rsh. Because the rsh port isn't bound, if any user could bind the rsh port, they could attack your system in the following way: many SSH distributions fall back to rsh automatically, with only a relatively minor security warning. By causing an SSH failure (exceeding, for example, its rate limited capacity), you could cause a fall-back to SSH. This is arguably a problem with the SSH clients, but is a real-world problem. Likewise, during reloads of common privileged daemons, the sockets bound to low port numbers will often be released. During those windows, an un-trusted user could bind the port, causing service failure, and allowing them to spoof the service. Both of these speak to the need for continued access control for these (and possibly other) ports. I've taken some time to look at some possible solutions to this, and do have an initial prototype that provides some of the functionality that might be required. This is done by abstracting the notion of an "object security label", which (as with ucred is for subjects) could be bound to arbitrary kernel objects, and express a policy for the use of the object. I've experimented with binding these object labels to a variety of kernel objects, using a number of policies (both discretionary and mandatory), but I'm not yet satisfied that this is the right solution, or that it can effectively describe the scope of desirable policies. You can imagine the following types of policies: (1) The root user is permitted to bind any port on any protocol using the IPv4 protocol domain for any use. (2) The "bind" user is permitted to bind the nameserver port using the UDP protocol using the IPv4 and IPv6 domains for any use. (3) The "bind" user is permitted to bind the nameserver port using the TCP protocol using the IPv4 and IPv6 domains for the purposes of receiving incoming connections only. (4) The "www" user is permitted to bind the http and https ports using the TCP protocol using the IPv4 domain and local address 192.168.11.200 for the purpose of receiving incoming connections only. (5) The "firewall" user is permitted to bind any port on any protocol using the IPv4 domain and local address 192.168.11.201 on the interface "dc0". Right now, I simply bind ACLs to each port number, regardless of address, and permission bits map into services depending on the protocol. For example, "read" and "write" for UDP map into the ability to receive and send packets using the port. For TCP, "read" and "write" map into the ability to receive connections and make outgoing connections. This mapping is pretty poor, especially once you're interested in extending from ACLs to mandatory policies, where "read" and "write" really need to mean "read" and "write", and not be euphamisms for connection policies. So my suspicion is that substantial further work is needed before we can move ahead here. This includes identifying the places where trust is placed in the value of the port number, identifying the consumers of various ports and the desirable policy scope, and implementing a policy specification that allows the desired policies to be expressed cleanly. And, needless to say, the performance overhead of these changes should be low, and usability high :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message