Hi * Ist there a possibility to set all ports above 1023 on a specific device to be "privileged" so only root can use them? I want to "prevent" users from sniffing e.g. X-sessions... Thanks in advance! Anibal
Hi! On Mon, 30 Oct 2000, Anibal Vasquez wrote:
Ist there a possibility to set all ports above 1023 on a specific device to be "privileged" so only root can use them? I want to "prevent" users from sniffing e.g. X-sessions...
I don't know how to set ports above 1023 to be privileged, but doing so is not necessary to prevent sniffing. In order to use a NIC to sniff network traffic, it must be in promiscuous mode, which can only be enabled by root. In other words: users are "prevented" from sniffing already. Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
Yuri Robbers wrote:
On Mon, 30 Oct 2000, Anibal Vasquez wrote:
Ist there a possibility to set all ports above 1023 on a specific device to be "privileged" so only root can use them? I want to "prevent" users from sniffing e.g. X-sessions...
I don't know how to set ports above 1023 to be privileged, but doing so is not necessary to prevent sniffing. In order to use a NIC to sniff network traffic, it must be in promiscuous mode, which can only be enabled by root. In other words: users are "prevented" from sniffing already.
Ohh, I´m sorry. The users I write about are logged in a machine running xdm for some X-terminals. These users could write their own programms to listen on the right ports on the machine, so they can sniff whole x-sessions. So if I can reserve all ports of the ethernet device connected to the X-terminals ro root no user would be able to to this, right? Thanks again, Anibal
Hi Anibal! On Mon, 30 Oct 2000, Anibal Vasquez wrote:
Ohh, I�m sorry. The users I write about are logged in a machine running xdm for some X-terminals. These users could write their own programms to listen on the right ports on the machine, so they can sniff whole x-sessions. So if I can reserve all ports of the ethernet device connected to the X-terminals ro root no user would be able to to this, right?
Perhaps, although I still don't know how to go about making these ports privileged. Why don't you use the X built-in security/access-control measures like MIT magick cookies? This would solve your problem, I think. Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
Ohh, I´m sorry. The users I write about are logged in a machine running xdm for some X-terminals. These users could write their own programms to listen on the right ports on the machine, so they can sniff whole x-sessions. So if I can reserve all ports of the ethernet device connected to the X-terminals ro root no user would be able to to this, right?
Thanks again, Anibal
Reserving ports or changing the "restricted" port range isn't the right
approach for this.
First off: The restricted ports scheme has been invented for
authentication based on trust of the root user of the client machine. It
is used in the "r"-utilities such as rlogin and rsh. A client opens a port
connection with a source port < 1024. Since the server knows that only
root can do that, the server can be sure that /usr/bin/rlogin (with
suid-root bit) was called on the client side. This is why the server
trusts the client-provided information about the client user's identity.
As you might imagine, this authentification mechanism is weak because
trusting the client is exactly what you don't want - you want a proof.
Extending the restricted port area to the range around port 6000/tcp would
not really improve security. You could keep users from starting X-servers,
yes. But once there is one running, it binds to port 6000 (if it has
display :0) on all available interfaces and interface addresses, and it
stays there. It is not possible for another process to listen to the same
addresses. This might have been your concern, right?
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Roman Drahtmueller wrote:
Reserving ports or changing the "restricted" port range isn't the right approach for this.
First off: The restricted ports scheme has been invented for authentication based on trust of the root user of the client machine. It is used in the "r"-utilities such as rlogin and rsh. A client opens a port connection with a source port < 1024. Since the server knows that only root can do that, the server can be sure that /usr/bin/rlogin (with suid-root bit) was called on the client side. This is why the server trusts the client-provided information about the client user's identity. As you might imagine, this authentification mechanism is weak because trusting the client is exactly what you don't want - you want a proof.
Extending the restricted port area to the range around port 6000/tcp would not really improve security. You could keep users from starting X-servers, yes. But once there is one running, it binds to port 6000 (if it has display :0) on all available interfaces and interface addresses, and it stays there. It is not possible for another process to listen to the same addresses. This might have been your concern, right?
Wow, thanks a lot! If I understand it right, this would also apply to the xdm running on my machine, so it´s not possible for a user to listen to any local port (on the machine running xdm) used by xdm for an existing X-connection to an X-terminal. Thanks! Does this topic have a name? I mean, what should I search the web for in order to get info like this? (So I don´t need to post it here :) Thanks again! Anibal
On Mon, Oct 30, 2000 at 15:27 +0100, Anibal Vasquez wrote:
Roman Drahtmueller wrote:
[ ... why you can't bind to a socket already in use ... ]
Wow, thanks a lot! If I understand it right, this would also apply to the xdm running on my machine, so it´s not possible for a user to listen to any local port (on the machine running xdm) used by xdm for an existing X-connection to an X-terminal.
Yes, you cannot listen to an ongoing connection over a socket you don't own (unless you can read the kernel's buffer for the socket, but if you can do this ...). All one could do is to setup another machine with a promiscous interface catching all the traffic. That's why physical security is just as important as secured software is, when you're serious about it.
Thanks! Does this topic have a name? I mean, what should I search the web for in order to get info like this? (So I don´t need to post it here :)
Try to read "man 2 socket" and follow the "SEE ALSO" section. "man 2 bind" will tell you about reasons why this could fail. One of those is "[EADDRINUSE] The specified address is already in use." Doc is not always "on the web". Sometimes (more often than one thinks) it's even on your local disk. :> virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (4)
-
Anibal Vasquez -
Gerhard Sittig -
Roman Drahtmueller -
Yuri Robbers