From owner-freebsd-security@FreeBSD.ORG Mon Jun 10 23:07:26 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C9872F7; Mon, 10 Jun 2013 23:07:26 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 787D01949; Mon, 10 Jun 2013 23:07:25 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r5AN7H2u083709; Mon, 10 Jun 2013 18:07:17 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r5AN7HCP083708; Mon, 10 Jun 2013 18:07:17 -0500 (CDT) (envelope-from brooks) Date: Mon, 10 Jun 2013 18:07:17 -0500 From: Brooks Davis To: Pawel Jakub Dawidek Subject: Re: Request for review: Sandboxing dhclient using Capsicum. Message-ID: <20130610230717.GF73639@lor.one-eyed-alien.net> References: <20130608223346.GA2468@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130608223346.GA2468@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 11 Jun 2013 02:05:27 +0000 Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:07:26 -0000 On Sun, Jun 09, 2013 at 12:33:46AM +0200, Pawel Jakub Dawidek wrote: > I'd appreciate any review, especially security audit of the proposed > changes. The new and most critical function is probably send_packet_priv(). I've looked over the diff and not found any significant issues, but have a few comments in order of most to least important. In change 229477 using a cached hostname may change behavior if the host is renamed as a result of dhclient operation. The new behavior might be more correct, at least it would be if we reliably restored the host name on termination. I think the change is fine, but we should be keep an eye out for problem reports. In change 229476 I noticed there is a constant 0x1fff that you've moved around. It was already there, but it seems like an unnecessary magic number. In the send_packet_* function declarations in dhcpd.h, you have included variable names which is inconsistent with the surrounding definitions. I saw a few style/whitespace fixed mixed in that should be batched, probably before the substantive commits. -- Brooks