bind() - Old/Current behaviour - Change?

From: Cefiar (cefiar1@optushome.com.au)
Date: Thu Oct 19 2000 - 06:52:30 EST


Hello all,
        During the recent thread "Re: bind() allowed to non-local addresses" there
is mention of change in the behavior of bind() re: allowing use of
non-local addresses between 2.2 and 2.4 series kernels.

Funnily enough, I've been playing with IPSec, Masqerading and so on for a
work project, and while muddling around with this stuff, I started thinking
it'd be a good thing to be able to limit the addresses a program could bind
to, to enforce certain types of routing on these programs. I immediately
thought of using something like IPchains/Netfilter to block packets going
out the interface, but after a little bit of investigation, I thought that
this sort of setup is an inelegant hack to do what is really necessary,
which is to simply not allow the programs to bind to the addresses in the
first place. Unfortunately to implement this sort of thing in god knows how
many user space programs looked like too much re-inventing of the wheel.

What I'm sort of envisioning is a small API (and user space interface
program) that can maintain lists like this for 2 sorts of instances:
  - Global conditions
  - Per-process conditions

Global conditions make it simple to remove an interface or address from the
bind sub-system. A IPADDR_ANY from ANY program will then only bind
addresses that are valid at the time the bind() is issued.

Per process conditions allow a program to set up an 'address jail' (where
the program that is invoked will only have the ability to bind() to a
limited subset of all the addresses available to the IP stack), or to
enable addresses that have been previously removed from the global
conditions . This allows programs to be set up with special requirements on
demand, without prior knowledge by the programmer for such conditions. Of
course such things would have to be inherited by child processes as well
(you could start restricted shells this way, where processes in the
restricted shell cannot bind to certain addresses).

Through both methods, this could allows things such as being able to 'bind'
a program to a non-local address, or remove addresses/interfaces that
should not be bound to (such as the PPP link you are trying to encrypt all
data out of using FreeS/WAN) by programs. Because it can be overridden on a
program by program basis, this allows things such as IKE (Internet Key
Exchange) or say VPS to still bind to such addresses as needed.

You could also 'lock' states so that new interfaces do not appear until
specifically instructed, or old interfaces do not disappear (useful for PPP
links and chroot'ed programs that bind to ports < 1024) when the interface
goes AWOL.

Notes:
        We can argue about all the defaults, but ultimately they should probably
be POSIX compliant, and probably not allow a program to bind() to just any
address. Such a system also allows 'new' defaults to be easily implemented
at boot before interfaces are even enabled (global conditions) as necessary.
        Of course, lots of per-process conditions could lead to a lot of
address/interface tables in memory. Funnily enough netfilter does pretty
much similar things with lists of addresses/interfaces, so it may be wise
to utilize some of netfilters methods in such a project.
        I also wouldn't be surprised if this sort of thing could (possibly) be
merged with netfilter. Wether that is a good thing is more up to Rusty than me.
        I don't know of anything that will do this, or even if it could be easily
implemented (doesn't sound that easy, but then, not much with the kernel
does). However I think the idea is sound, and could at least do with some
consideration.

Anyway, enough of my bantering.. time for everyone to comment.

--
  -=[ Stuart Young (Aka Cefiar) ]=-------------------------------
  | http://amarok.glasswings.com.au/ | cefiar1@optushome.com.au |
  ---------------------------------------------------------------

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:14 EST