From owner-freebsd-net@freebsd.org Thu Nov 28 22:51:13 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FE551BB090 for ; Thu, 28 Nov 2019 22:51:13 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47PCYD1Qvtz4Byt; Thu, 28 Nov 2019 22:51:12 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vk1-xa36.google.com with SMTP id u6so4485029vkn.13; Thu, 28 Nov 2019 14:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14Ske9bLwaPHOs1Da5aWAY+LCViCmhS+EsVBGC63IFM=; b=X/haHJVpJhID9HRMXeODxZz+/i0tjuccI4PXWuvt+8eqS/NuovFhX2o4eOGO94+YwZ cu5JjjpGoX87LCm8SxvY1Sv8T42Lp31T5RP2IpyD5OyYhLfiT9E11MnsuQvvga5JVidO EJsU84pPm1UsdiES4MeSfwcR3xviBTqqLrMgfuVaMwgy3M0VCl6nsBwyr3wzYVkQIK0D LFGQDZJpU1ieN0J1+lcVyTMEzXEYVb6iJEsfTQwQrvUpahRmHYDKjKp+HSK6KzAJAkj7 cwit2bb0WgNbIK74Xjq9gKnYQ9W3fWMXkybG+ljRREZ0zu/qY1PuU3Nr1JqShtpVFo5M oDyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14Ske9bLwaPHOs1Da5aWAY+LCViCmhS+EsVBGC63IFM=; b=Cg24p6GmDgTHYA556W6jibRxX14VJpCHulKSYn4WLn3+R3dVH7r44TZopzsPvq1a8l YQOvI9NMmmEFHrZVtgGVnFzOs46kC0d2r0uw/gYKTdxwethuDV5Oj+MEJAJcCXSNkXL8 f1l1na9u5wKcvvXx5AXeBNlkG/Gyk7lpTfqPTurkIPLqlZLnkkdgZkFOaTzOuXXyerjt 2XVxJxz4T2ETv+hsGYYkbhYKPrvTlh0NXmOt04vXNKrwYEFMIKdHVILdMazbJcKDx+Sp HmN98y5rtlxYnemi9yjMa2n0MzGbyEIBXPRfjvCdws1OiNby5Rlr/91j1EToaRZwnRav EiSg== X-Gm-Message-State: APjAAAW+wCaEjLwN0YCkOI3Z6trL8Nq31oRGiWwsPoOCTKPdJahVW0Ay Ezu1Jd2vHIJotljydatD35umEG7CVAqnLozo9FaRpvz0 X-Google-Smtp-Source: APXvYqwytkD3jSQxQfvV11PwIVX7d+corPhM1S9nUR7JRGvoEYyx7+9v5IOsOHOauAeYdC04LZCFGzun+7tFR8K3T0s= X-Received: by 2002:a1f:e086:: with SMTP id x128mr2036835vkg.32.1574981470958; Thu, 28 Nov 2019 14:51:10 -0800 (PST) MIME-Version: 1.0 References: <20191014.043209.919156653743886519.hrs@allbsd.org> <20191015.215732.1618848784026596315.hrs@allbsd.org> In-Reply-To: <20191015.215732.1618848784026596315.hrs@allbsd.org> From: Ben Woods Date: Fri, 29 Nov 2019 06:50:59 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato Cc: brooks@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org, hrs@freebsd.org, julian@freebsd.org, roy@marples.name X-Rspamd-Queue-Id: 47PCYD1Qvtz4Byt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=X/haHJVp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::a36 as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[6.3.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.28), ipnet: 2607:f8b0::/32(-2.26), asn: 15169(-1.94), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 22:51:13 -0000 On Tue, 15 Oct 2019 at 9:00 pm, Hiroki Sato wrote: > Roy Marples wrote > in : > 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. Hi Everyone, FYI, Roy (upstream dhcpcd developer) has recently committed privilege separation to dhcpcd. It is not yet enabled by default until he gets more feedback from others that it is working ok. I intend to update the FreeBSD port to enable this feature (perhaps with a =E2=80=9C-devel=E2=80=9D port) to allow it to be te= sted more easily on FreeBSD. Mailing list message: https://roy.marples.name/archives/dhcpcd-discuss/0002711.html Commit: https://github.com/rsmarples/dhcpcd/commit/d5786118da1bad4c247631cae86344f1= b249a8cb Regards, Ben > -- -- From: Benjamin Woods woodsb02@gmail.com