Date: Thu, 16 Aug 2001 10:14:28 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: cjclark@alum.mit.edu Cc: David Malone <dwmalone@maths.tcd.ie>, Mikhail Teterin <mi@aldan.algebra.com>, alex@big.endian.de, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <Pine.NEB.3.96L.1010816100053.84244B-100000@fledge.watson.org> In-Reply-To: <20010816000823.H330@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <badger@tislabs.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010816100053.84244B-100000>