Date: Fri, 8 Jul 2011 13:08:00 +0100 From: "Robert N. M. Watson" <robert.watson@cl.cam.ac.uk> To: matt@ixsystems.com Cc: Ilya Bakulin <webmaster@kibab.com>, Jonathan Anderson <jonathan.anderson@cl.cam.ac.uk>, Ben Laurie <benl@google.com>, freebsd-hackers@freebsd.org Subject: Re: Capsicum project: Ideas needed Message-ID: <57BDDB28-E356-4C61-B9E2-88FBF38A6F78@cl.cam.ac.uk> In-Reply-To: <CAK6u07UyQJyz%2BvXmxK1VA5vQPzRdL=7efFNtVRWshHkifK%2BH%2Bw@mail.gmail.com> References: <4E167C94.70300@kibab.com> <CAK6u07UyQJyz%2BvXmxK1VA5vQPzRdL=7efFNtVRWshHkifK%2BH%2Bw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57BDDB28-E356-4C61-B9E2-88FBF38A6F78>