Reserving "special" port numbers in the kernel ?

Reserving "special" port numbers in the kernel ?

[Arun Sharma]

One of the Intel server platforms has a magic port number (623) that
it uses for remote server management. However, neither the kernel nor
glibc are aware of this special port.

As a result, when someone requests a privileged port using
bindresvport(3), they may get this port back and bad things happen.

Has anyone run into this or similar problems before ? Thoughts on
what's the right place to handle this issue ?

        -Arun

Re: Reserving "special" port numbers in the kernel ?

[Xavier Bestel]

Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.
> 
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
> 
> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?

run a dummy app at startup which reserves that port ?

Re: Reserving "special" port numbers in the kernel ?

[Arun Sharma]

xavier.bestel@free.fr (Xavier Bestel) writes:

> Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
> > One of the Intel server platforms has a magic port number (623) that
> > it uses for remote server management. However, neither the kernel nor
> > glibc are aware of this special port.
> > 
> > As a result, when someone requests a privileged port using
> > bindresvport(3), they may get this port back and bad things happen.
> > 
> > Has anyone run into this or similar problems before ? Thoughts on
> > what's the right place to handle this issue ?
> 
> run a dummy app at startup which reserves that port ?

Yes, I'm already aware of this one, but was looking for a lighter weight
solution (ideally a config file change) that doesn't involve running an
extra process (think of doing this on a large number of machines).

        -Arun

Re: Reserving "special" port numbers in the kernel ?

[Sean Neakums]

commence  Arun Sharma quotation:

> xavier.bestel@free.fr (Xavier Bestel) writes:
>
>> Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
>> > One of the Intel server platforms has a magic port number (623) that
>> > it uses for remote server management. However, neither the kernel nor
>> > glibc are aware of this special port.
>> > 
>> > As a result, when someone requests a privileged port using
>> > bindresvport(3), they may get this port back and bad things happen.
>> > 
>> > Has anyone run into this or similar problems before ? Thoughts on
>> > what's the right place to handle this issue ?
>> 
>> run a dummy app at startup which reserves that port ?
>
> Yes, I'm already aware of this one, but was looking for a lighter weight
> solution (ideally a config file change) that doesn't involve running an
> extra process (think of doing this on a large number of machines).

inetd

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: Reserving "special" port numbers in the kernel ?

[Randy.Dunlap]

On 15 Nov 2002, Arun Sharma wrote:

| xavier.bestel@free.fr (Xavier Bestel) writes:
|
| > Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
| > > One of the Intel server platforms has a magic port number (623) that
| > > it uses for remote server management. However, neither the kernel nor
| > > glibc are aware of this special port.
| > >
| > > As a result, when someone requests a privileged port using
| > > bindresvport(3), they may get this port back and bad things happen.
| > >
| > > Has anyone run into this or similar problems before ? Thoughts on
| > > what's the right place to handle this issue ?
| >
| > run a dummy app at startup which reserves that port ?
|
| Yes, I'm already aware of this one, but was looking for a lighter weight
| solution (ideally a config file change) that doesn't involve running an
| extra process (think of doing this on a large number of machines).

Look in arch/i386/kernel/setup.c (in 2.4.19):

There is this array:
  struct resource standard_io_resources[] = ...
that you could add to; you could even make the addition a CONFIG_ option.

-- 
~Randy
  "I read part of it all the way through." -- Samuel Goldwyn

Re: Reserving "special" port numbers in the kernel ?

[Arun Sharma]

rddunlap@osdl.org ("Randy.Dunlap") writes:

> Look in arch/i386/kernel/setup.c (in 2.4.19):
> 
> There is this array:
>   struct resource standard_io_resources[] = ...
> that you could add to; you could even make the addition a CONFIG_ option.

That's reserving I/O ports. Are you suggesting that we create an
analogous array for IP ports ?

        -Arun

Re: Reserving "special" port numbers in the kernel ?

[Randy.Dunlap]

On 15 Nov 2002, Arun Sharma wrote:

| rddunlap@osdl.org ("Randy.Dunlap") writes:
|
| > Look in arch/i386/kernel/setup.c (in 2.4.19):
| >
| > There is this array:
| >   struct resource standard_io_resources[] = ...
| > that you could add to; you could even make the addition a CONFIG_ option.
|
| That's reserving I/O ports. Are you suggesting that we create an
| analogous array for IP ports ?

Nope.  Sorry, I read too much into "port".  :(
or maybe too much port.

-- 
~Randy
  "I read part of it all the way through." -- Samuel Goldwyn

Re: Reserving "special" port numbers in the kernel ?

[Alan Cox]

On Sat, 2002-11-16 at 00:00, Arun Sharma wrote:
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.

I can't find it in the IETF standards documents either.

> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.

They have at least as much right to it as you do

> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?

Run your remote management daemon from xinetd, it'll then get the port
nice and early in the system runtime.

Re: Reserving "special" port numbers in the kernel ?

[Arun Sharma]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Sat, 2002-11-16 at 00:00, Arun Sharma wrote:
> > One of the Intel server platforms has a magic port number (623) that
> > it uses for remote server management. However, neither the kernel nor
> > glibc are aware of this special port.
> 
> I can't find it in the IETF standards documents either.

It's been registered as a well known port:

http://www.iana.org/assignments/port-numbers

[..]

> 
> > Has anyone run into this or similar problems before ? Thoughts on
> > what's the right place to handle this issue ?
> 
> Run your remote management daemon from xinetd, it'll then get the port
> nice and early in the system runtime.

The thing that's unique about our situation is that the daemon in not
user level. It runs at hardware/firmware level, so that you can
remotely administer the machine even when software is malfunctioning.

        -Arun

Re: Reserving "special" port numbers in the kernel ?

[Alan Cox]

On Sun, 2002-11-17 at 16:37, Arun Sharma wrote:
> The thing that's unique about our situation is that the daemon in not
> user level. It runs at hardware/firmware level, so that you can
> remotely administer the machine even when software is malfunctioning.

So you've got an administration port that ignores the firewall
facilities on the machine. Now tell me why anyone would buy such a
product ? What if your firmware has a network layer bug, what if someone
finds a security hole in it ?

If you want to steal ports from under the OS then you need your own IP
address and full network stack, not the one assigned to the Linux
system. 

Alan

Re: Reserving "special" port numbers in the kernel ?

[Willy Tarreau]

On Fri, Nov 15, 2002 at 04:00:37PM -0800, Arun Sharma wrote:
> 
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.
> 
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
 
The problem is that you want bindresvport() to fail and your bind() to
succeed, but bindresvport() calls bind(), so there's no way to distinguish
them.

But if you're willing to modify a bit your app and the kernel, at least there
would be a method. You could find a way to mark some ports "RESERVED", so that
bind() fails on them unless the socket has been set to SO_REUSEPORT. It's
unlikely that a caller of bindresvport() would set this flag on its socket.
But when you know you want this port for your app, you could explicitly set it.

This concept could be extended to reserve unprivileged ports. Eg, we could
mark 1521, 3128, ... reserved, so that only proper apps could bind on them,
and more importantly, connect() wouldn't use them.

Cheers,
Willy

Re: Reserving "special" port numbers in the kernel ?

[Chris Wedgwood]

On Fri, Nov 15, 2002 at 04:00:37PM -0800, Arun Sharma wrote:

> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel
> nor glibc are aware of this special port.

Odd.

charon:~% grep -c 623 /etc/services
0

rfc1700:

[...]

WELL KNOWN PORT NUMBERS

The Well Known Ports are controlled and assigned by the IANA and on
most systems can only be used by system (or root) processes or by
programs executed by privileged users.

[...]

npmp-gui        611/tcp    npmp-gui
npmp-gui        611/udp    npmp-gui
#                          John Barnes <jbarnes@crl.com>
ginad           634/tcp    ginad
ginad           634/udp    ginad


I don't see port 623 in there.  Where is this documented?

> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.

Indeed.   It seems like they should be able to get this port.

What bad things happen?

> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?

User-land.  Fix broken applications.



  --cw