Run dhclient inside the sandbox

* In order to ensure that network interfaces are already configured when
  the sandboxed launches, we run dhclient in forking mode (no -d switch),
  which makes the dhclient command exit when it successfully acquired a lease.
  The dhclient daemon process keeps running in the background.
* We read the pid file for dhclient to find out the pid of the daemon process.
  Because dhclient only writes the pid file in the child process potentially
  after the forking parent process exits, there is some handling for possible
  race conditions.
* All lease files and pid files are under /run/firejail/dhclient/
* The v4 and v6 dhclient has a separate lease as recommended.
* The v4 client is set to generate a DUID, which is also used by the v6 client
  so that the server can associate the two leases if needed.
* /etc/resolv.conf is created in the sandbox just like with the --dns option,
  by mirroring /etc. When DHCP is used, /etc/resolv.conf is normally empty so
  that dhclient can overwrite it the nameservers from the DHCP server.

Current limitations:
* The dhclient processes in the background are not terminated properly
  (by SIGTERM or dhclient -x), nor is the DHCP lease released (by dclient -r).
  The reason for this is that firejail drops all capabilities and privileges
  before the application in the sandbox is launched, which makes it impossible
  to launch dhclient to release the lease or kill the dhclient processes still
  running with the effective user id of root. Instead the dhclient daemons
  die with the sandbox. According to the dhclient man page, releasing the lease
  is not required by the DHCP specification, so this is not a problem, however
  some ISPs may require releasing leases.
  A possible workaround would be to fork another process upon sandbox
  initialization that invokes dhclient -r when the sandbox is ready to exit.
  This would require communication with the main firejail process through
  a pipe, while keeping and required privileges. As this would add some
  complexity but the benefits have limited applicability (compatibility with
  esoteric DHCP server configurations), I chose not to implement this.
* When only an IPv6 address is requested, the interface may possible not have
  a link-local address when we run dhclient. This causes dhclient -6 fail,
  since DHCPv6 uses link-local addressing instead of layer 2 addressing,
  see e.g., https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783387
  In a future commit, waiting for a link-local address will be added.

1 files changed, 5 insertions, 0 deletions

diff --git a/src/include/rundefs.h b/src/include/rundefs.h
index df135b9ca..8119f31e9 100644
--- a/src/include/rundefs.h
+++ b/src/include/rundefs.h
@@ -49,6 +49,11 @@
 #define RUN_LIB_DIR                     RUN_MNT_DIR "/lib"
 #define RUN_LIB_FILE                    RUN_MNT_DIR "/libfiles"
 #define RUN_DNS_ETC                     RUN_MNT_DIR "/dns-etc"
+#define RUN_DHCLIENT_DIR      RUN_MNT_DIR "/dhclient"
+#define RUN_DHCLIENT_4_LEASES_FILE      RUN_DHCLIENT_DIR "/dhclient.leases"
+#define RUN_DHCLIENT_6_LEASES_FILE      RUN_DHCLIENT_DIR "/dhclient6.leases"
+#define RUN_DHCLIENT_4_PID_FILE      RUN_DHCLIENT_DIR "/dhclient.pid"
+#define RUN_DHCLIENT_6_PID_FILE      RUN_DHCLIENT_DIR "/dhclient6.pid"
 
 #define RUN_SECCOMP_DIR                 RUN_MNT_DIR "/seccomp"
 #define RUN_SECCOMP_LIST                RUN_SECCOMP_DIR "/seccomp.list"         // list of seccomp files installed