Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Aug 1995 11:32:10 +0100 (BST)
From:      Paul Richards <paul@netcraft.co.uk>
To:        pete@puffin.pelican.com (Pete Carah)
Cc:        current@FreeBSD.ORG
Subject:   Re: workaround for talk's address problem
Message-ID:  <199508081032.LAA03138@server.netcraft.co.uk>
In-Reply-To: <199508071909.MAA09580@puffin.pelican.com> from "Pete Carah" at Aug 7, 95 12:09:46 pm

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Pete Carah who said
> 
> In article <199508062229.XAA24522@server.netcraft.co.uk> you write:
> >In reply to J Wunsch who said
> >> The correct solution would be asking the routing socket to see which
> >> interface address must be used to get in contact with the remote peer.
> >> Unfortunately, the interface to the routing socket is somewhat ugly to
> >> use and it requires root privileges.  Hence i'm suggesting the
> >> following workaround.  It introduces an option `-a' followed by a
> >> (dotted-quad) address to use for the negotiation.  This address will
> >> be checked against the address list as returned from gethostbyname()
> >> to avoid abusing foreign addresses.
> 
> >I want to add an option like this to everything. I'm running a multi-homed
> >host that has *lots* (or will have) of ip addresses and I also
> >need to have, for instance, a sendmail connected to each address to handle
> >services for that particular domain.
> THIS *SHOULD* be possible to use (if possible) with no mods to the
> client/server program source.  This would eliminate the problem of
> needing listens on all possible interfaces like xntpd now does.

Ehh, I'd be interested to know how? All the servers in the tree at the
moment bind to INADDR_ANY. The funtionality I'm adding is the ability to
make servers bind to a particular address and only that particular address
which is something we can't currently do.

Incidentally, I've run into another, rather more difficult problem.

If the local socket isn't specifically bound, which usually it isn't
then in_pcbconnect (or in_pcbladdr as it is now I think) will try and
find an appropriate value. This is a problem if you're trying to do what
I'm doing. For instance, I've got a web server running in one virtual
enviromment, say, foo.com and a browser in another, say bar.com.

When in_pcbconnect gets called, I think what's happening is that the
decision about the local addr is made by ifa_ifwithnet, since the
destination address is an ip address aliased on this host it finds
an ifaddr struct that has a match and it returns that as the local
address. The result is that the web server in foo.com thinks the browser
is also connecting from foo.com even though it's really connecting from
bar.com.

It knackers security up completely if a client from one domain can
access servers in another because the local addr of the client gets
set to that of the server and not the client! In a multi-homed
environment this seems bogus to me. 

I'd like this to be changed in some way but I'm not exactly sure
what the best way is. We could check the destination address and if
it's actually an aliased address on this host then *not* return that
as the local addr, that would solve the problem with bogus domains
as I'm seeing above but I'm not sure how to work out what the correct
local addr would be. What I want to happen is for the local addr to
be set to the ip address of whatever hostname is. How much of a cludge
would it be to do that? Since this would only happen if the dst addr was
an exact match for an alias it wouldn't affect the cases where packets
actually get out onto the wire and the local addr needs to be set to the
outgoing interface.


-- 
  Paul Richards, Bluebird Computer Systems. FreeBSD core team member. 
  Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
  Phone: 0370 462071 (Mobile), +44 1222 457651 (home)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508081032.LAA03138>