On 07.04.2011 13:31, Robert N. M. Watson wrote: > 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]. >> >> 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. >> >> 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. >> >> 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 > !DSPAM:4d9d84a210433086818784! > >
Hi Robert, thank you for your comments. I've posted a project proposal to GSoC website [1]. I've tried to take your suggestions into account. If there are any questions, I'll be happy to answer them. [1] http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/kibab/1 -- Regards, Ilya Bakulin http://kibab.com xmpp://[email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
