GSOC : Draft proposal for capsicum

[Joris GIOVANNANGELI <joris@xxxxxxxxxxxxxxxx>]

(it looks like my first mail did not go to the list because i was not 
subscribed.
Sorry if it was sent twice)

Hi,

I'm a 4th year CS student at Université Diderot Paris 7. I don't really 
have any
public open source C code yet, but it's a good time to start ! I've 
attended two
OS/System class, one on Unix kernel internal, and the other on POSIX 
API. I've
been reading parts of the DragonFly kernel during the laste year, and 
writting some
hammering code to get familiar with it. I've already started a capscium 
port,
but it's still in an early state. I wrote those patches in december, but 
most of
them are outdated since FreeBSD reworked the capsicum kernel API since that
(keeping a compatibility layer). HEre is a draft proposal. Since some code
whould be quite pervasive in the kernel, please comment !

                                     CAPSICUM

Capsicum is a fine grained capability framework for unix systems. It can 
be use
to sandbox applications by restructing 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. Capscum is currently implemented in the FreeBSD kernel, and some 
work is
ongoing on the linux side.

                                    KERNEL PART

Capsicum extends various POSIX API and add some others. The kernel part 
are :

  * Capability mode : a process mode, set by a system call, in which 
acces to
    global namespaces is restricted. For instance, system calls like 
open(2),
    socket(2) might not be used. The capability mode is inherited by the 
child
    processes. Once in capability mode, only the delegated rights may be 
used.

  * Capabilities : rights can be attached to file descriptors to 
restrict access.
    Descriptors already have access flags, but nothing prevents you tu 
upgrade a
    readonly file descriptor to a read-write one. Capabilities can be 
granted by
    a set of system calls.

  * Process descriptors : on POSIX systems, you can only manage process by
    accessing the PID namespace. To allow parent pids to manage childs 
while
    in capability mode, a new API have been created. Like file descriptors,
    they are local descriptors for process and can be managed by a set of
    syscalls : pdfork, pdkill, pdwait4 and pdgetpid.

  * Shared memory : anonymous shared memory has been extended to allow 
shared
    memory segment to be referenced and accessed by descriptors.

                                  USERSPACE PART

The userspace tools and libraries are still a moving target.

  * Applications and livrariies have to be converted to capsicum. Rights 
have to
    be defined for various critical libraries, and some tools have to be 
splitted
    between a worker process in capability mode and a control process.

  * libcapsicum : a library is beeing created to ease the developpement of
    capsicum-enabled tools.

  * casper is a prototyped daemon which offers various services to 
process in
    capability mode, like DNS resolution.

                                   PROJECT GOALS

The userspace implemnetations are not yet finalized and a lot of them could
be ported from FreeBSD once they are done. This proposal is mostly about 
the
kernel APIs. The goal is to have an implementation of the various syscalls
compatible with the FreeBSD kernel API.

The shared memory extension has already been implemented in dragonfly. 
Hence,
only the first three parts have to be implemented, with the glue needed to
integrate them in the kernel and the build system (for instance, the 
capability
mode flag has to be add to the process structure).

                                     TIMELINE

I could start coding in June.

  - 3 weeks :
    Implement capabilities for filedescriptos in kern_descrip.c. 
White-listed
    capabilities have to be attached to each filedesc. An Ioctls 
white-list is
    needed, which means dynamically alloced space for each 
filedescriptor with
    such list. Capabilities are check each time a process gets a file 
opinter
    from a file descriptot.

  - 3 weeks :
    Capability mode. This include a set of syscall to set/get 
capabilities of a
    descriptor, fork/rpces integration, and maybe some ktrace 
integration for
    debugging purpose. In this area the code skeleton from freeBSD can 
be reused,
    but not "as-is", due to different locking mechanisms.

  - 2 weeks :
    Add capability checks ti various syscalls : *at(2), nlookup, sysctl. 
This
    should be fairly easy, but at this point, I should have a semi-working
    capsicum implementation, and it whould be a good time to do some 
testing.

  - Mid-term evaluation

  - 3 weeks :
    proces descriptor API. Add 4 syscalls  pdfiork, pdwait4, pdkill, and 
pdgetpid
    which use file descriptor-like API to reference processes.

  - 2 weeks :
    Add connectat() and bindat() syscalls for UNIX domain sockets. Their 
behavior
    whould be similar to the *at syscall familly.

  - remaining time :
    Check the syscalls list, the sysctl and the ioctls list to identify 
the safe
    ones, and to more testing of the whole implementation. If possible, 
try to
    port some FreeBSD tool which uses capsicum and make it run.

                                          LINKS

capsicum project page : http://www.cl.cam.ac.uk/research/security/capsicum/



Thanks for reading,
                                                           Joris 
GIOVANNANGELI