Date: Thu, 7 Apr 2011 10:31:53 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Ilya Bakulin <webmaster@kibab.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Capsicum application adaptation and core libraries Message-ID: <CBCBED32-2248-436B-9E82-F1149B195E96@freebsd.org> In-Reply-To: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com> References: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 Apr 2011, at 10:13, Ilya Bakulin wrote: > some time ago I've read a paper about Capsicum (it was published at = Google > reseach papers page). I think that this is an interesting technology, = and > adopting it for use in FreeBSD base system is worth an effort. Also I = see > this idea as GSoC suggested idea on Ideas page [1]. >=20 > So I'd like to take this as a possible GSoC project for this summer. = As > the task description seems to be very broad, I'd like to be more = specific > about what is to be done during the summer. >=20 > As core Capsicum libraries will appear in FreeBSD 9 anyway, I think = it's > possible to take several applications from the base system and modify = them > to use Capsicum sandboxes. For example, the FreeBSD syslog daemon = might be > an interesting application to adapt to compartmentalisation model. = Exact > list of applications that will be adapted is to be discussed. Primary > focus should be, however on "sbin" and "usr.sbin" world parts. >=20 > Do you think that this work may be useful? Hi Ilya: I think this sort of project would be great for Google Summer of Code. A = results-oriented effort, which starts with a specific set of system = services or components, and works back into their dependencies (such as = critical libraries, missing Capsicum features, etc) sounds like a good = way to go about it. A key question throughout, needs to be "what is = protected from whom" -- each use of compartmentalisation comes with = performance cost and code complexity, and selecting the most valuable = applications will be a central part of the work. Critical system services, such as syslogd, etc, sound like good places = to begin, as well as nailing down use of Capsicum in dhclient, sshd, = etc, which we've experimented with but haven't yet merged into FreeBSD. = It would also be interesting to apply Capsicum to pipeline components = such as gzcat, grep, sed, nroff (and in the future, and perhaps a better = match, mandoc), so that when components operate on streams and don't = require additional inputs and outputs, they operate entirely in = sandboxes. As will become clear once you dig in, there are some missing things = needed to really round out the Capsicum API. The web page refers largely = to "services" for sandboxes -- as capability mode forbids creating new = network connections, potential services to sandboxes include passing in = pre-connected sockets, files/subtrees based on policy, etc, that might = be expressed somehow: by the application writer during sandbox setup, or = be dynamic in response to changing situations. Another interesting direction to run in might be to start pushing = Capsicum support into higher level applications that desperately need = it: PDF rendering, for example! There's a lot of interesting work to be = done here. However, the remaining proposal period is pretty short -- I'd = encourage you to put together as concrete a proposal as possible -- = necessarily somewhat open-ended, but lay out in moderate detail how = you'd spend the first month: specific policy and security goals, = concrete tasks, elements to change, and what you think the challenges = are, etc. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CBCBED32-2248-436B-9E82-F1149B195E96>