Initial commit.

DESIGN

@@ -0,0 +1,104 @@
+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
+