(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
