78 lines
		
	
	
		
			2.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			78 lines
		
	
	
		
			2.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
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.
 | 
						|
 | 
						|
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
 | 
						|
 |