<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 12:08 AM, Joris GIOVANNANGELI <span dir="ltr"><<a href="mailto:joris@giovannangeli.fr" target="_blank">joris@giovannangeli.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<br>
i'm part of GSOC this year, and i will work on an implementation of Capsicum kernel APIs for DragonFly.<br>
<br>
                                                CAPSICUM<br>
<br>
Capsicum is a fine grained capability framework for unix systems. It can be use to sandbox applications by restricting their access to various global namespaces. While DAC and unix rights grant access at the user level, capscium is designed to implement security policies at the application or library level. Unlike MAC frameworks (SELinux, AppArmor, ...) where access profile is configured out of the code, capsicum sandboxing policy might directly be built in the application itself. Capsicum is currently implemented in the FreeBSD kernel, and some work is ongoing on the linux side.<br>

<br>
                                                 PROJECT<br>
<br>
I plan to work on 3 main subprojects :<br>
    - capabilities : rights attached to file descriptors. Each operation on a filedescriptor is check against the set of rigths the filedescriptor carries. If the filedescriptor has not enougth rights, the operation fails. Typical capabilities are CAP_READ, CAP_WRITE, CAP_FCNTL, etc.<br>

    - capability mode : a credential flag is add to each process. When in capability mode, to determine wether the capabilities are taken in consideration or not. When a process has been put in capability mode, it cannot exit the sandbox by itself, and it cannot gain new capabilities by itself, except by the use of  *at syscalls (e.g openat). New capabilities can be granted to a process.<br>

    - process descriptors : add support for a new type of filedescriptors, pointing to processes. This will permit local naming of processes, for sandboxing purposed, and the fork/kill operations will be implemented.<br>

<br>
                                                  WORK<br>
<br>
My work will be avaible on github [1], in capsicum branch.  You can also read my draft proposal [2] on this list, or the last version on the github wiki [3]. My nick is joris on #dragonflybsd@efnet.<br>
<br>
I'm happy to work on dragonfly this summer !<br>
<br>
Joris GIOVANNANGELI<br>
<br>
[1] <a href="https://github.com/jorisgio/DragonFlyBSD" target="_blank">https://github.com/jorisgio/<u></u>DragonFlyBSD</a><br>
[2] <a href="http://lists.dragonflybsd.org/pipermail/kernel/2013-April/031197.html" target="_blank">http://lists.dragonflybsd.org/<u></u>pipermail/kernel/2013-April/<u></u>031197.html</a><br>
[3] <a href="https://github.com/jorisgio/DragonFlyBSD/wiki/proposal" target="_blank">https://github.com/jorisgio/<u></u>DragonFlyBSD/wiki/proposal</a><br>
</blockquote></div><br>Awesome :-)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I read the timeline. I'd be happy to see the end-result merged into the release. Do you think you'll have time to integrate</div>
<div class="gmail_extra">the work upstream even after the gsoc ? </div><div class="gmail_extra"><br></div><div class="gmail_extra" style><br></div><div class="gmail_extra"><div><br></div>-- <br><div dir="ltr"><div style="text-align:left">
This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.</div><br><br>                                            <br><br></div>
</div></div>