DHCPv6 client in base

[Hiroki Sato]

Roy Marples <roy at marples.name> wrote
  in <f3c51ba5-ebad-4f2f-2ae5-ab08055f6b6b at marples.name>:

ro> On 13/10/2019 20:32, Hiroki Sato wrote:
ro> > Ben Woods <woodsb02 at gmail.com> wrote
ro> >    in
ro> >    <CAOc73CBzvRD0Je5+XQJ9_UqTP2_cgJvc7_7JTU0fjKBCVnTt-w at mail.gmail.com>:
ro> > wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods <woodsb02 at gmail.com>
ro> > wrote:
ro> > wo> As promised, I have completed my initial work to import dhcpcd
ro> > into FreeBSD
ro> > wo> base, and it is ready for review, testing and comment at the link
ro> > below.
ro> > wo> https://reviews.freebsd.org/D22012
ro> > wo>
ro> > wo> As per the comment from brooks@, I have opted to have it installed
ro> > in
ro> > wo> parallel with dhclient (which remains the default).
ro> >   How do you want to proceed the discussion?  I sent my view and made
ro> >   myself clear that importing dhcpcd into the base system as-is is not
ro> >   a good idea.  What is your answer to my concerns?  I also agree with
ro> >   Brooks about a need for sandboxing before the import if it will
ro> >   happen.  Do you have any plan to add changes to the imported dhcpcd?
ro>
ro> Sorry if it was not clear. The discussion involves what is the
ro> required acceptance for Priviledge Seperation because this is quite
ro> new to me.
ro>
ro> My current idea is to open DHCP, IPv6RA and DHCP6 ports, chroot, drop
ro> privs and fork. This concept is pretty standard thus far. These are
ro> listening ports only and will dry-run any received message through
ro> dhcpcd's two commons paths:
ro>   1) extract address and routing information without applying it
ro>   2) environment option generation from the whole message

 A typical separation is three process model which contains
 processes for 1) sending/accepting packets (and parsing them), 2)
 state machine for each protocol handling, and 3) global namespace
 access (file, routing socket, network interface state, etc).  The
 superuser privilege can be dropped in 1) and 2) completely.  1) and
 3) communicate with 2) on demand or event-driven basis.  1) do not
 communicate directly with 3).  Protocol-specific routines are in 1)
 and 2)---the former handles its wire-format, and the latter deals
 with protocol-specific state machines.

 However, this is often an overkill for a small, single-protocol
 network daemon.  A two process model which contains one for 1)+2) and
 another for 3) above is used in sbin/dhclient, for example.  I think
 this separation is the minimum level.  3) performs privileged tasks
 such as ioctls for network interfaces.

 I believe the three process model is appropriate for dhcpcd because
 of the nature of multi-protocol support.  Parsing is one of the
 attack surfaces.  For instances, a dhcp6_findoption() loop in
 dhcp6_recv() should be in process 1 and changes of D6_STATE(ifp)
 should be managed in process 2.  The current dhcp6_bind() directly
 uses dhcp6_findmoption() to extract options from a DHCP message on
 demand and also directly accesses the global namespace by using
 dhcp6_writelease(ifp).  These packet inspection and file access can
 be replaced with IPC requests to process 1 or 3 in the model, and it
 can be realized without a big structural change to the original logic
 in dhcp6.c (though it requires a certain amount of changes to the
 current code).

 In the ideal world everything should work fine and this kind of
 separation just sounds to make the program complex unnecessary, but
 an incomplete separation between the possible attack surfaces and
 access to the global namespace does not provide a good security even
 if the superuser privilege dropped.

 Note that these are just my own view, not a requirement for something
 nor feature request.  I think lack of privsep must be considered if
 dhclient is replaced, but I also think replacing dhclient is beyond
 the discussion of DHCPv6.

 Anyway, You might want to create a new email thread for sandboxing of
 dhcpcd on FreeBSD if you want to continue to discuss it.  Probably
 developers with more expertise in security can make a comment.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20191015/207de52b/attachment.sig>