2010-11-12 14:32:18 +05:30
|
|
|
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
|
|
|
|
|
|
2010-12-24 21:19:45 +05:30
|
|
|
a. Don't try to handle severe errors.
|
2010-11-12 14:32:18 +05:30
|
|
|
|
|
|
|
|
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
|
2010-12-24 21:19:45 +05:30
|
|
|
standardized, but remain necessary features.
|
|
|
|
|
|
2010-11-12 14:32:18 +05:30
|
|
|
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
|
|
|
|
|
|
