The manual page says, that rcmd() is only to be used by root's processes. On other OSes (Solaris, AIX), trying to call rcmd() without being root simply fails. FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. Why? My understanding is, this is to make it harder for would-be attackers to attack machines with .rhosts-based security. But that is nothing more than a bad band-aid anyway -- attacker's own implementation of rcmd() (without the geteuid() checks) is trivial... So, without providing any meaningful security improvement (who is relying on .rhosts for security anyway?!), we are impeding a very useful functionality. rcmd offers an efficient way to send your data to a command "abroad" and even has a mechanism for getting the remote's stderr -- assuming, your network is secure enough for you to trust .rhosts. Why are we duplicating the misguided efforts of commercial Unixes and limiting it to root only? "Mechanism, not policy", please... -mi
On Fri, Jul 07, 2006 at 08:30:01PM -0400, Mikhail Teterin wrote:> The manual page says, that rcmd() is only to be used by root's processes.DESCRIPTION The rcmd() function is used by the super-user to execute a command on a remote machine using an authentication scheme based on reserved port num- bers. Note that only root can bind to reserved ports.> On other OSes (Solaris, AIX), trying to call rcmd() without being root simply > fails. > > FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which > is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. > > Why? > > My understanding is, this is to make it harder for would-be attackers to > attack machines with .rhosts-based security. But that is nothing more than a > bad band-aid anyway -- attacker's own implementation of rcmd() (without the > geteuid() checks) is trivial...But an attacker who doesn't have root won't be able to use their own implementation of rcmd(). It will just fail. Either the attacker will ask to bind to a privileged port (which will fail at the local host), or they will bind to a non-privileged port (in which case the remote host will reject the request) rsh is a setuid root binary. It is able to bind to privileged ports, whilst performing security checks that the requested access is valid. In the same way, the 'passwd' command lets you change your own password, without letting you change someone else's.> So, without providing any meaningful security improvement (who is relying > on .rhosts for security anyway?!), we are impeding a very useful > functionality.No security improvement is implied. Rather, you just get extra functionality. Instead of a dead failure, certain non-root requests are allowed (i.e. user A on host X can run commands as user A on host Y)> rcmd offers an efficient way to send your data to a command "abroad" and even > has a mechanism for getting the remote's stderr -- assuming, your network is > secure enough for you to trust .rhosts.And the requesting user is running as root, so they can bind to a privileged port.> Why are we duplicating the misguided efforts of commercial Unixes and limiting > it to root only?Because this is exactly how the .rhosts security model works - it accepts requests only from privileged ports, which in turn means that it knows the request only came from root. This mechanism is only valid for trusted hosts, of course. If you allow a random person to put their own PC on the network, they can of course send packets from privileged ports (either by installing Unix with their own root password, or by installing DOS and sending packets which come from privileged ports) HTH, Brian.
Brian Candler wrote:> Note that only root can bind to reserved ports....> This mechanism is only valid for trusted hosts, of course. If you allow a > random person to put their own PC on the network, they can of course send > packets from privileged ports (either by installing Unix with their own root > password, or by installing DOS and sending packets which come from > privileged ports)I gather that it is now possible to disable the privileged ports thing on FreeBSD at least. (Thank heavens, I say :) iang
On 2006.07.10 16:07:06 +0200, Iang wrote:> Brian Candler wrote: > > >Note that only root can bind to reserved ports. > > ... > > >This mechanism is only valid for trusted hosts, of course. If you allow a > >random person to put their own PC on the network, they can of course send > >packets from privileged ports (either by installing Unix with their own > >root > >password, or by installing DOS and sending packets which come from > >privileged ports) > > I gather that it is now possible to disable the > privileged ports thing on FreeBSD at least. > > (Thank heavens, I say :)Actually it is, but it would obviously be a stupid idea to do so any place where privileged ports are required... [simon@zaphod:~] sysctl net.inet.ip.portrange.reservedhigh net.inet.ip.portrange.reservedlow net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 -- Simon L. Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20060710/a1820e4b/attachment.pgp