From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 8 12:08:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5BD01065678 for ; Fri, 8 Jul 2011 12:08:02 +0000 (UTC) (envelope-from robert.watson@cl.cam.ac.uk) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 693998FC1A for ; Fri, 8 Jul 2011 12:08:02 +0000 (UTC) Received: from c0129.aw.cl.cam.ac.uk (c0129.aw.cl.cam.ac.uk [128.232.100.129]) by cyrus.watson.org (Postfix) with ESMTPSA id 915C846B53; Fri, 8 Jul 2011 08:08:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Fri, 8 Jul 2011 13:08:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57BDDB28-E356-4C61-B9E2-88FBF38A6F78@cl.cam.ac.uk> References: <4E167C94.70300@kibab.com> To: matt@ixsystems.com X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 08 Jul 2011 12:21:51 +0000 Cc: Ilya Bakulin , Jonathan Anderson , Ben Laurie , freebsd-hackers@freebsd.org Subject: Re: Capsicum project: Ideas needed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 12:08:02 -0000 On 8 Jul 2011, at 05:02, Matt Olander wrote: > What about inetd? Is that possible or does each service it support > need sandboxing, too? How about sendmail and bind? I'm less concerned about the core connection juggling content of inetd = than the external services it launches -- however, inetd has a number of = built-in services that do interpret and manipulate untrustworthy data = (even if only in basic ways), and directly sandboxing them with Capsicum = would be very useful. I'd also like to see some focus on network command line tools -- = especially things like dig, ping, finger, host, etc, which tend to not = need access to things after some threshold moment, and/or can motivate = compartmentalisation work on libraries such as the resolver. At this = point we should go for easy wins with 100% correctness. (Getting a version of the resolver working with sandboxed Capsicum stuff = seems like a priority: it's a known issue with our sandboxed tcpdump, so = modifying lwresd or similar so it can work with UNIX domain sockets, and = teaching the resolver code to use them, would be excellent.) Robert=