ndhc/DESIGN
Nicholas J. Kain 7a09ba2cf7 Initial commit.
2010-11-12 04:02:18 -05:00

105 lines
3.6 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.
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