Re: Use reserved port only when required for NIS look-ups

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Fri, Aug 10, 2012 at 9:22 AM, Honza Horak <hhorak@redhat.com> wrote:
> we have a request from user [2] to use reserved port only when required for
> NIS look-ups. This is the case we need to address:
>
> When non-root user asks NIS server for any information, unprivileged port is
> used on client side, so there are enough ports to use. However, when root
> asks NIS server for any information, reserved port is used every-time.
> Having a client with many look-ups with root privileges we can get to a
> state where all reserved ports are exhausted and some other services that
> need to bind to a reserved port can eventually fail.

Correct.

> One ancient discussion about limited reserved ports count with regards to
> well-known ports is available at [1], but this is something different.
>
> This is reason why we can't simply use unprivileged ports for all look-ups:
>
> NIS server is able to be "secured" with a configuration, where administrator
> marks some maps as "secure" (basically maps with passwords) and only
> connections form a reserved port are served in that case. So if we used
> non-reserved ports for all look-ups, some of them wouldn't be served.

I've never seen a "secured map," out of curiosity how does someone set one up?

> HP's solution to address this is described like as follow:
>
> "Reserved ports are the ports from 0 to 1024. Only root users can bind to
> these ports. In previous releases, NIS commands attempted to bind to
> reserved ports by default. If there are numerous client requests, all the
> reserved ports can be consumed. This version of NIS enables binding to
> reserved ports for select commands or daemons when accessing secure maps
> which results in reduced usage of reserved ports by NIS. This change does
> not compromise performance or security."

This makes sense.

It *does* compromise security, but increases performance (by providing
more available ports).

More than that it provides *choice* to the ISV or admin.

Whenever you use a non-privileged port there is the risk of the daemon
getting killed and a rogue daemon using the port to talk to the client
and pretend to be authoritative.

If you only use privileged ports then this isn't an issue, the user
already needs to have control of a privileged process to bind to one
of these ports, and if that's the case you have worse problems.

> I'd like to propose a similar behavior, ie. to limit use of reserved ports
> only for "secured maps" requests. The problem is, that client currently
> doesn't know which maps are marked "secured" on the server. Because of that
> we'd have to introduce a new client-side configuration option or environment
> variable (used in a patch attached) to define secure maps on client side.
> That configure option could default to "all", which would mean the same as
> the current behavior.

This worries me. I don't like adding configuration files if we don't have to.

Why doesn't the client know which maps are marked secure? Didn't we
just configure the secure maps?

> I'm not aware of any security implications that would be introduced by using
> unreserved ports, but I'm not a security expert.

I think it's more about choice.

You allow some of your maps to be served from non-privileged ports and
in doing so you recognize that they might get spoofed via a certain
attack vector.

It's harder if you had used a privileged port.

It's even more problematic when root is making the requests because
the spoofed data might get used to mislead a process that has root
privileges. This is dangerous.

Granted this is all about choice and if you wish you should mark all
of your maps secure.

Cheers,
Carlos.