DragonFly BSD
DragonFly kernel List (threaded) for 2013-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Capsicum GSOC project


From: Loganaden Velvindron <loganaden@xxxxxxxxx>
Date: Fri, 7 Jun 2013 10:02:17 +0400

--e89a8f3bab8558af4c04de8a2ca8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 7, 2013 at 12:08 AM, Joris GIOVANNANGELI <joris@giovannangeli.fr
> wrote:

> hi,
>
> i'm part of GSOC this year, and i will work on an implementation of
> Capsicum kernel APIs for DragonFly.
>
>                                                 CAPSICUM
>
> 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.
>
>                                                  PROJECT
>
> I plan to work on 3 main subprojects :
>     - 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.
>     - 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.
>     - 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.
>
>                                                   WORK
>
> 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.
>
> I'm happy to work on dragonfly this summer !
>
> Joris GIOVANNANGELI
>
> [1] https://github.com/jorisgio/**DragonFlyBSD<https://github.com/jorisgio/DragonFlyBSD>
> [2] http://lists.dragonflybsd.org/**pipermail/kernel/2013-April/**
> 031197.html<http://lists.dragonflybsd.org/pipermail/kernel/2013-April/031197.html>
> [3] https://github.com/jorisgio/**DragonFlyBSD/wiki/proposal<https://github.com/jorisgio/DragonFlyBSD/wiki/proposal>
>

Awesome :-)

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
the work upstream even after the gsoc ?



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

--e89a8f3bab8558af4c04de8a2ca8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Jun 7, 2013 at 12:08 AM, Joris GIOVANNANGELI <span dir=3D"l=
tr">&lt;<a href=3D"mailto:joris@giovannangeli.fr"; target=3D"_blank">joris@g=
iovannangeli.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">hi,<br>
<br>
i&#39;m part of GSOC this year, and i will work on an implementation of Cap=
sicum kernel APIs for DragonFly.<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 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, capsc=
ium is designed to implement security policies at the application or librar=
y level. Unlike MAC frameworks (SELinux, AppArmor, ...) where access profil=
e is configured out of the code, capsicum sandboxing policy might directly =
be built in the application itself. Capsicum is currently implemented in th=
e FreeBSD kernel, and some work is ongoing on the linux side.<br>

<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0PROJECT<br>
<br>
I plan to work on 3 main subprojects :<br>
=A0 =A0 - capabilities : rights attached to file descriptors. Each operatio=
n 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>

=A0 =A0 - capability mode : a credential flag is add to each process. When =
in capability mode, to determine wether the capabilities are taken in consi=
deration 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 =A0*at syscalls (e.g openat). New capabilities can be =
granted to a process.<br>

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

<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 WORK<br>
<br>
My work will be avaible on github [1], in capsicum branch. =A0You 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&#39;m happy to work on dragonfly this summer !<br>
<br>
Joris GIOVANNANGELI<br>
<br>
[1] <a href=3D"https://github.com/jorisgio/DragonFlyBSD"; target=3D"_blank">=
https://github.com/jorisgio/<u></u>DragonFlyBSD</a><br>
[2] <a href=3D"http://lists.dragonflybsd.org/pipermail/kernel/2013-April/03=
1197.html" target=3D"_blank">http://lists.dragonflybsd.org/<u></u>pipermail=
/kernel/2013-April/<u></u>031197.html</a><br>
[3] <a href=3D"https://github.com/jorisgio/DragonFlyBSD/wiki/proposal"; targ=
et=3D"_blank">https://github.com/jorisgio/<u></u>DragonFlyBSD/wiki/proposal=
</a><br>
</blockquote></div><br>Awesome :-)</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">I read the timeline. I&#39;d be happy to see t=
he end-result merged into the release. Do you think you&#39;ll have time to=
 integrate</div>
<div class=3D"gmail_extra">the work upstream even after the gsoc ?=A0</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style><br><=
/div><div class=3D"gmail_extra"><div><br></div>-- <br><div dir=3D"ltr"><div=
 style=3D"text-align:left">
This message is strictly personal and the opinions expressed do not represe=
nt those of my employers, either past or present.</div><br><br>=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 <br><br></div>
</div></div>

--e89a8f3bab8558af4c04de8a2ca8--



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]