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/ | [EMAIL PROTECTED] |
  ---------------------------------------------------------------

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

Reply via email to