Reserving "special" port numbers in the kernel ?
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
Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
Quoted 9 lines
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 ?
Quoted 5 lines · [email protected] (Xavier Bestel) writes:
Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
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
commence Arun Sharma quotation:
Quoted 10 lines
Quoted 8 lines · [email protected] (Xavier Bestel) writes:
Le sam 16/11/2002 à 01:00, Arun Sharma a écrit :
Quoted 7 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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
Signature · 4 lines
/ | [|] Sean Neakums | Questions are a burden to others; [|] <[email protected]> | answers a prison for oneself. \ |
On 15 Nov 2002, Arun Sharma wrote:
| [email protected] (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.
Signature · 2 lines
~Randy "I read part of it all the way through." -- Samuel Goldwyn
Quoted 5 lines · [email protected] ("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 aCONFIG_option.
That's reserving I/O ports. Are you suggesting that we create an analogous array for IP ports ?
-Arun
On 15 Nov 2002, Arun Sharma wrote:
| [email protected] ("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.
Signature · 2 lines
~Randy "I read part of it all the way through." -- Samuel Goldwyn
Quoted 3 lines · 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.
I can't find it in the IETF standards documents either.
Quoted 2 lines
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
Quoted 2 lines
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.
Quoted 7 lines · 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.
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
Quoted 3 lines · 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.
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 <[email protected]> ginad 634/tcp ginad ginad 634/udp ginad
I don't see port 623 in there. Where is this documented?
Quoted 2 lines
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?
Quoted 2 lines
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
Quoted 6 lines · Alan Cox
Quoted 3 lines · 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.
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
[..]
Quoted 6 lines
Quoted 3 lines
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
Quoted 3 lines · Arun Sharma
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