DONE
Using the kernel to redirect all outgoing traffic (any IP) from vservers to the horizon server.
Modify the protocol so the target IP is provided to the blackhole server. This allows for example
controlled access to the internet.

TODO
have a way to express a deny. Currently, all request without a rule goes to the reject mecanism.
Sometime, it may be useful to just point a rule to the DENY master and the request will
be rejected. For now, this is kind of done using the blackhole-devnull service.

TODO
The blackhole server may trigger an alarm when a connection is attempted but match no rules. This is
especially interesting if a vserver, all of a sudden, is trying to reach the internet, while
normally, it only connects to a database server.

DONE, just an idea
(With the REDIRECT iptable features, it is posssible to redirect anything coming from a vserver
to the horizon and the horizon will know the original port. So the horizon only have to listen
on one port on the loopback and it grabs everything)
The horizon server may listen on as many port as possible, creating some honey pot for intruders
in a vserver. Whenever an intruders opens one of those ports (and the blackhole server has no rules
for them for this specific vserver), an alarm is triggered.

DONE
Using /proc/net, tries to identify the process at the other end of the local TCP socket, and then
the program (the binary). Then we can expand the rules to contain the program name. Since a vserver
is usually running with /usr read-only, it can't lie there.

The utility findproc demonstrate that it is easy to do. Now we can enhance the connect request
sent to blackhole, to contain:
	-The uid (translated to a name)
	-the path of the program
	-the pstree path of the process
	-The token of the process (See the explanation at the end)

TODO
The rules in blackhole are easily updated on the fly. They can be modified using a cron for example.
A vserver may normally access only a database server, but during some hours, it may access an archiver.
Using the idea above, a vserver may only access a database using its main application, but for debugging
and admin may change the rules to allow another program (a database shell) to run, to perform special
database maintenance.

DONE
Could it support UDP ? udpproxy kind of do the job

TODO
Pending request on horizon must die after few seconds. This happens when a blackhole let a wormhole
handle a connection, but this wormhole has improper connectivity with the two horizon servers (or
just one). So it can't send either a reject or link command. So the connection hangs forever.
There is an issue here. A pending connection may take a while to work, but if we close it too soon, another
connection may come through and be associated with the old. Tricky...

(Although the clean up is still needed, the security issue above is not possible (see testrace.tlcc))

DONE
Horizon server must provide a secret when a blackhole connects. So if a server is abused and made to crash and
some other server tries to impersonate it, it won't work because it lacks the secret. Note that if a server is abused
and fail, blackhole will notice within 5 seconds. blackhole for now reconnect on its own. It may be changed so
it reconnect only when told.

TODO
Use the proof of work to prevent an horizon from flooding the blackhole.

-------------------------------------

Token concept:

This is not a blackhole thing, but blackhole make this thing very useful. The idea is that processes in a
vserver are not created equal. Imagine that the first process of a vserver is given a TOKEN at the vserver
creation. This token, like the vserver xid, is inherited by sub-process, but following some simple rules. One rule
could be that a sub-process inherited the token, minus one (the token is a number). An exec syscall would also lower
the token value.

There is no way for the process
to manipulate the token value. So imagine that you start a vserver as root with a token value of 10, then you run
a startup script with a token value of 9. Then one service startup script is called, with 8 and eventually, the daemon
starts with 7, then fork to go in background, so end up with 6. So a blackhole connection rule would be (say apache connects
to a mysql server

	master-server vservername ip0 tcp-port-of-mysql apache /usr/sbin/httpd 6

Now, if apache is abused, and the intruder got a shell and tries to reach the database, it won't connect and blackhole
will trigger an alarm (not implemented at this time).