Capsicum project: Ideas needed

[Jonathan Anderson]

On 8 July 2011 12:09, Ilya Bakulin <webmaster at kibab.com> wrote:
> modification of inetd itself is NOT sufficient and
> ineffective, capability support implies modifying code of daemons

Speaking as someone who isn't terribly familiar with inetd:
One could imagine inetd (or an inetd-like service) accepting
connections, wrapping them up with capability rights masks, and
forking capability-mode daemons that can't e.g. reconnect a socket.
See comments about unmodified binaries, below.


>> -any interpreter (perl, python, etc)?
> Proper capsicumization of these things requires heavy code hacking, and
> probably won't be accepted by upstream anyway, until Capsicum becomes a
> standard not only for BSD world. Should hold on for now.

Fair enough. I think the language-level things are probably a better
target for CTSRD, whose vocabulary includes fine-grained memory
regions, rather than (relatively coarse) files and processes.


>> -any shell?...
> Processes that are started by the shell will inherit its capabilities. So
> this is undesirable IMHO. We should modify applications themselves.

Do take a look at https://github.com/trombonehero/capsh, which is a
(not-fully-functional-as-a-shell-yet) capability-aware shell. It
executes child processes in capability-mode sandboxes, providing
access to explicitly named resources via library preloading (replacing
the regular open() and friends, which will die with ECAPMODE, with
versions that search through a list of explicitly inherited files).
The philosophy is a bit like Plash, but the details are built on
Capsicum foundations.

As I said, I wouldn't call it functional yet, but it does allow me to
run simple binaries, e.g. cat, unmodified but in a sandbox. So while I
agree that it's good to modify applications to take advantage of
Capsicum, there is some exploration to be done in bringing
Capsicum-backed security improvements to unmodified applications.


>> minicom
>> wget
>> curl
>> links/lynx
> This is Ports software, we may try to modify it and even send patches to
> upstream, or maintain our local patches. I wanted to focus on base system
> components during GSoC, but it doesn't hurt to try to capsicumize these
> tools either.
>
> From your first email:
>> How about sendmail and bind?
> I don't know how many people actually use sendmail in base system?
> Regarding bind -- it's a good idea, though bind already includes support
> for running in jail AFAIK.

Both of these do seem like ideal candidates. Jail support is actually
a plus: it means that some of the compartmentalization work might
already be done for you, and provides a comparison point (evaluation
with Jail, Capsicum and Jail+Capsicum).


>> Can it be made a switch on sudo?
>> sudo --sandbox=someprofile,option tcpdump -tti pflog0

Interesting... this starts to sound a bit like Mac OS X's sandbox
policy files ("run this binary, constrained by policy X.sb"). I think
that the capsh/Plash approach is a more natural fit for capabilities
(policy files fit nicely with MAC), and indeed, a more natural tool
for the job we're trying to do here.

Perhaps 'sudo --sandbox command infile:r outfile:rw' could do
something very much like what capsh tries to do.


Jon
-- 
Jonathan Anderson

Research Student, Security Group
Computer Laboratory
University of Cambridge

+44 (1223) 763747
jonathan.anderson at cl.cam.ac.uk