Date: Fri, 8 Jul 2011 13:00:12 +0100 From: Jonathan Anderson <jonathan.anderson@cl.cam.ac.uk> To: Ilya Bakulin <webmaster@kibab.com> Cc: Matt <sendtomatt@gmail.com>, freebsd-hackers@freebsd.org, "Robert N. M. Watson" <robert.watson@cl.cam.ac.uk>, Ben Laurie <benl@google.com> Subject: Re: Capsicum project: Ideas needed Message-ID: <CAMGEAwCfp_%2Bb89kJ-6KgkY943j9=B2dgQ3KSA-n6HGs7VMzfsg@mail.gmail.com> In-Reply-To: <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> References: <4E167C94.70300@kibab.com> <4E1685D8.403@gmail.com> <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 July 2011 12:09, Ilya Bakulin <webmaster@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@cl.cam.ac.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMGEAwCfp_%2Bb89kJ-6KgkY943j9=B2dgQ3KSA-n6HGs7VMzfsg>