SOC2011IlyaBakulin [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Project Description =====

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. Currently I see the following milestones for this project:

1. Determine the current state of Capsicum integration in %%FreeBSD%% – obviously nessesary to know. This includes compiling the respective Perforce branch to see what's going on there. Also I plan to get in touch with people involved in implementing initial Capsicum prototype for %%FreeBSD%%. This may be done during the Community Bonding Period, as this doesn't involve writing any code and hence doesn't break %%GSoC%%'s rules. **DONE**

2. Build a list of applications that should be adapted to use enhanced security model. I've received some suggestions that applications interacting with network should be changed first. This includes various system services (syslogd, sshd, DNS resolver, inetd and it's slave servers). Requires discussion with $mentor though. **DONE -- there was a discussion on hackers@**

3. For each of such applications, discuss with hackers@/$mentor how to implement required sandboxing better. This will also highlight what features should be added to Capsicum framework itself ("services" for sandboxes?) **Currently in progress**

4. Based on the applications list described in the previous step, decide which of them should be implemented during this %%GSoC%%, consider every application as a milestone, implement. So people will be able to test and discuss the changes.If some application requires libcapsicum changes, do it first, announce update, discuss it, then implement application changes. **Currently in progress**

===== Testing =====
As security issues in %%FreeBSD%% are usually not known prior to their announcement on freebsd-security (usually with patches for correcting situation), I think that functional testing should involve playing with procstat(1) to determine opened file descriptors, etc (as in original Capsicum paper published by Google), maybe other instruments for other sets of resources.

Also it's possible to insert "malicious" code into the parts of application that are believed to be potentiallly vulnerable (compression/decompression routines, parsing code) and show that this code isn't able to do harm when operating in sandboxed environment.

Regression testing would involve measuring performance overhead introduced by capability checks.