Re: Security through Permissiveness: A Zen Riddle?

pollardat_private

Shane Kerr <shane@time-travellers.org>:
> <offtopic level="slight">
> 
> On 2001-07-17 19:53:06 -0400, jmjonesat_private wrote:
> > 
> > It would seem to me that the restriction of "system ports" to the
> > first 1024 ports was an "early" attempt to address forward security
> > needs.  As such, it was INCREDIBLY successful... showing simple
> > solutions CAN have great impact.
> 
> How so?  In my mind, the direct cause of the root exploits of machines
> through sendmail, bind, ftp, etc, etc.
> 
> And it's not consistent.  Consider:
> 
> socks  1080

Socks is a redirector, not a recognized service

> nfs    2049

2049 was a convention, it is not mandatory. The portmap utility,
which does use a "system" port is used to point to it.

> lockd  4045

Same.

> irc    6667

Does not require any privileges, it is a convention.

> https  8080

This isn't even the standard port - port 80 is (and is a "system" port).
Port 8080 was originally used for demos and debugging for "gopher" so
that the server could be debugged by a normal user.

> Why don't *these* ports (for starters) need protection?  *grumble*

> > It may be possible to open ports other than 0-1023 for "system" access
> > in linux, but they probably aren't going to ever become "universal".
> > Quite honestly, PORTS are a construct that MUST be universal under
> > TPC/IPC to really work.
> 
> I don't know.  If an application does:
> 
>   if (bind(fd, &addr, ...) == -1) {
>       perror("Unable to bind address");
>       exit(1);
>   }
> 
> Then it can work under an OS that allows non-root processes to bind
> ports in the privileged range, and require root on others, without any
> special coding.
> 
> > Many weeks ago, somebody suggested creating port structures in /proc/
> > that refected the specific ports being opened and their permissions.
> > This is one way to handle this within the pre-existant paradigm that I
> > like, but not enough to "bid on".
> 
> This seems like implementation to me - as long as the hooks are there an
> LSM can do what it wishes.  If the hooks work like:
> 
>   if ((port < 1024) && biguglyprocess_struct->uid) {
>       return EPERM;
>   }
>   if (fancykernelhook->lsm->bindhook) {
>       ret = (fancykernelhook->lsm->bindhook)(port);
>       if (ret) return ret;
>   }
> 
> Then no LSM can ever implement a policy to allow non-root users to bind
> low ports.

Actually it can, but shouldn't. The original set of reserved ports were
reserved for specific functions, with unused ports for future use. Most
of the functions, outside of the network test and support functions, were
those used that required user authorization (telnet, ftp, rsh, rlogin,
rexec, exec, remote job entry type of thing). Additional functions added
were mail (not really authenticated, but if it had the proper protocol
then...).  There were several service advertising functions (DNS, rpcbind,
news, whois, printer ...) added that needed some level of assurance that
the service was valid.

At the time the easiest was to say "if it uses a reserved port, then the
facility authorizes access and is responsible for the function".  Without
reserved ports there is/was no way to make any claims as to the validity
of the service. With reserved ports, the site could be held responsible for
what was being presented. Even now, "unknown services" are usually reported
as privileged ports being open for listen, without a "defined" function
(true, other ports are reported as "unknown" too, depending on the port
scanner and the policy on port usage).

In a small network of a 100 systems, in a single facility - this was enough.
rsh/nfs both use "trusted host" + a UID from that host to determine if
access to the local host was permitted (without password).

In larger networks, it was necessary to know that a service (telnet/ftp) was
comming from an authorized source and not spoofed by a trivial program. Once
M$ decided to NOT follow the existing standards and practices, then the
relatively low security of the network completely failed.

Only those ports in /etc/services and below 1024 have been activly pushed
as standard. There are even UNIX implementations that push the reserved list
up to port 4096, which would cover NFS (mostly). Others allow the limit
to be modified (I don't remember if it allowed less than 1024, but I think
the upper limit was 8192).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module