105 lines
3.6 KiB
Plaintext
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
|
|
|