Goals:

1.  Security

	a.  Divide into seperate processes that each have the minimal
	    system access necessary to complete their task.

	b.  Use a well defined IPC mechanism to facilitate cooperation
	    between processes.  In this case, UNIX domain sockets are
	    used, since they allow for UNIX DAC (on Linux, at least).

	c.  Write each program to be secure; don't rely on the
	    privilege seperations for security.

	d.  Simple error handling is favored rather than complex error
	    handling that may possibly be caused to "recover" in an
	    exploitable way.

	e.  Don't make stupid assumptions.  Implement only the minimal
	    functionality necessary to perform a task.  Expect brain
	    damaged or malicious inputs.

	f.  Run inside a chroot, with minimal privileges via
	    capabilities or MAC.

2.  Reliability

	a.  Don't try to handle severe errors.  

	b.  Log errors if program state is still sane.

	c.  Recover from predictable problems if necessary.  Make sure
	    that recovery behavior is well understood and defined.

	d.  Complicated or unsafe recoveries should not be performed;
	    instead the program should promptly exit.  Dead programs
	    don't cause exploits.

5.  Portability

	a.  Portability is good, but portability may not be as wide as
	    a less secure program.  Capabilities or MAC are not well
	    standardized, but remain necessary features.  
	
        b.  Aside from the previous caveat, try to be as portable as
	    possible.  At the very least, the dhcp client daemon
	    should be easily portable (only broadcast and perhaps RAW
	    packets are necessary).

98. Speed

	a.  If we aren't required to sacrifice anything more
	    important, it's always good to be fast.

99. Size

	a.  If we aren't required to sacrifice anything more
	    important, it's always good to be frugal.


Specifics:

Implementation language will be C.  C is universally available, very
predictable, and well accepted.  dhcp clients don't have to deal with
complicated data structures or extensively with strings, so C's
largest weaknesses should not be highly apparent.  On the other hand,
dhcp clients must extensively deal with the OS in a low-level fashion.
C's strongest points will therefore be used.

More practically, a program written in a compiled language other than
C will be poorly accepted by the average user.  Since widespread use
is an eventual goal of ndhc, this point is very eloquent.

For now, I'm taking advantage of the existing udhcpc.  With minor
modifications, it will serve quite well as the dhcp client daemon.  It
is then only necessary for me to write a client request translator
and a interface change daemon.  The result should be a highly modular
solution.

I'm developing on a Linux-based platform.  ndhc will first be designed
to work properly on a Linux-based system.  I will then make certain
that ndhc works well on a RSBAC-enabled Linux system.  Afterwards, I
_may_ spend some effort porting ndhc to FreeBSD (but don't count on it).  I
have no personal interest in other platforms.

Layout:


ndhc daemon  (root -> chroot -> drop all !(CAP_NET_BROADCAST|CAP_NET_RAW) 
              -> nopriv)

* handles dhcp protocol issues
* keeps track of leases
* talks to ndhif to perform tasks that require
  higher privileges than CAP_NET_BROADCAST or CAP_NET_RAW

ifchd daemon  (root -> openfd -> chroot -> drop all !CAP_NET_ADMIN -> nopriv)

* listens for interface change requests via UNIX domain socket
* restricts valid IP ranges that will be accepted
* performs interface changes
* keeps rw fds for system files (such as /etc/resolv.conf) that must
  be modified outside the chroot