From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 8 12:21:39 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 D8EBF106564A for ; Fri, 8 Jul 2011 12:21:39 +0000 (UTC) (envelope-from jra40@hermes.cam.ac.uk) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by mx1.freebsd.org (Postfix) with ESMTP id 74E078FC18 for ; Fri, 8 Jul 2011 12:21:38 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail-pw0-f54.google.com ([209.85.160.54]:42241) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:jra40) (TLSv1:RC4-SHA:128) id 1Qf9jC-0006XH-pl (Exim 4.72) for freebsd-hackers@freebsd.org (return-path ); Fri, 08 Jul 2011 13:00:14 +0100 Received: by pwi7 with SMTP id 7so1435069pwi.13 for ; Fri, 08 Jul 2011 05:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.25.1 with SMTP id y1mr2515299pbf.169.1310126412523; Fri, 08 Jul 2011 05:00:12 -0700 (PDT) Received: by 10.68.62.39 with HTTP; Fri, 8 Jul 2011 05:00:12 -0700 (PDT) In-Reply-To: <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> References: <4E167C94.70300@kibab.com> <4E1685D8.403@gmail.com> <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> Date: Fri, 8 Jul 2011 13:00:12 +0100 Message-ID: From: Jonathan Anderson To: Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Sender: Jonathan Anderson X-Mailman-Approved-At: Fri, 08 Jul 2011 12:35:27 +0000 Cc: Matt , freebsd-hackers@freebsd.org, "Robert N. M. Watson" , Ben Laurie 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:21:40 -0000 On 8 July 2011 12:09, Ilya Bakulin wrote: > modification of inetd itself is NOT sufficient and > ineffective, capability support implies modifying code of daemons Speaking as someone who isn't terribly familiar with inetd: One could imagine inetd (or an inetd-like service) accepting connections, wrapping them up with capability rights masks, and forking capability-mode daemons that can't e.g. reconnect a socket. See comments about unmodified binaries, below. >> -any interpreter (perl, python, etc)? > Proper capsicumization of these things requires heavy code hacking, and > probably won't be accepted by upstream anyway, until Capsicum becomes a > standard not only for BSD world. Should hold on for now. Fair enough. I think the language-level things are probably a better target for CTSRD, whose vocabulary includes fine-grained memory regions, rather than (relatively coarse) files and processes. >> -any shell?... > Processes that are started by the shell will inherit its capabilities. So > this is undesirable IMHO. We should modify applications themselves. Do take a look at https://github.com/trombonehero/capsh, which is a (not-fully-functional-as-a-shell-yet) capability-aware shell. It executes child processes in capability-mode sandboxes, providing access to explicitly named resources via library preloading (replacing the regular open() and friends, which will die with ECAPMODE, with versions that search through a list of explicitly inherited files). The philosophy is a bit like Plash, but the details are built on Capsicum foundations. As I said, I wouldn't call it functional yet, but it does allow me to run simple binaries, e.g. cat, unmodified but in a sandbox. So while I agree that it's good to modify applications to take advantage of Capsicum, there is some exploration to be done in bringing Capsicum-backed security improvements to unmodified applications. >> minicom >> wget >> curl >> links/lynx > This is Ports software, we may try to modify it and even send patches to > upstream, or maintain our local patches. I wanted to focus on base system > components during GSoC, but it doesn't hurt to try to capsicumize these > tools either. > > From your first email: >> How about sendmail and bind? > I don't know how many people actually use sendmail in base system? > Regarding bind -- it's a good idea, though bind already includes support > for running in jail AFAIK. Both of these do seem like ideal candidates. Jail support is actually a plus: it means that some of the compartmentalization work might already be done for you, and provides a comparison point (evaluation with Jail, Capsicum and Jail+Capsicum). >> Can it be made a switch on sudo? >> sudo --sandbox=someprofile,option tcpdump -tti pflog0 Interesting... this starts to sound a bit like Mac OS X's sandbox policy files ("run this binary, constrained by policy X.sb"). I think that the capsh/Plash approach is a more natural fit for capabilities (policy files fit nicely with MAC), and indeed, a more natural tool for the job we're trying to do here. Perhaps 'sudo --sandbox command infile:r outfile:rw' could do something very much like what capsh tries to do. Jon -- Jonathan Anderson Research Student, Security Group Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.anderson@cl.cam.ac.uk