On Thu, Mar 13, 2014 at 1:01 AM, Jean-Philippe Ouellet <jean-phili...@ouellet.biz> wrote: > On 3/12/14 4:58 AM, tuchalia wrote: >> Should l try to port also the Casper daemon to OpenBSD, or >> only work in the kernel implementation? > > Based on more private mail, I figured it'd be a good idea to make what I > plan to work on public in case there are others interested so we can > avoid stepping on each others' toes. > > I've been told that the OpenBSD project's main objective in supporting > capsicum is to have stronger privsep in our default services (think ssh, > etc.) and the first steps to support that are the relevant kernel > changes, therefore that's what I plan to work on first.
Also, please note that OpenBSD supports multiple architectures. > > I wasn't planning on doing anything with casper, user angels, etc. and > even porting libcapsicum was a 2ndary objective, at least not during > this summer. Unbound crashes on FreeBSD-capsicum enabled kernels. (http://unbound.net/pipermail/unbound-users/2014-February/003169.html) I would suggest that you come up with a regression plan to test the demons in base and the most popular one in ports. In this case, unbound was not capsicumised, but the changes made to the kernel affected unbound. Also, please look into FreeBSD's regression test suite for capsicum. > > There's also a ton of userland things besides daemons/services that > could (probably should) be capsicumized. Good testing coverage is also very important, in addition to sandboxing. There's going to be a lot of follow-up to do. I would suggest that you contact the maintainers and see who is interested in getting capsicum into their demon. The response may be varied. > > Just yesterday there was just a vuln reported by the debian folks in > their file(1) that potentially allowed arbitrary code execution. I > immediately checked our implementation and didn't see the same code that > was patched, but our src/usr.bin/file/softmagic.c still contains a ton > of logic which probably has at least one bug somewhere, and file(1) > should be a fairly easily capsicumizable utility. I've read about the file vulnerability , and capsicumization also came to mind. However, there was also a discussion when i was playing with capsicum and openssh, about the limits of capsicum. Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD in addition to capsicum. (https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2013-August/msg00000.html) > > Userland capsicumization is something that could very easily be done by > multiple people since it's naturally separated into small chunks (per > utility). I planned to focus on getting the primary kernel > infrastructure in place this summer (because it's a somewhat large > project, and it would definitely help to be sponsored by Google so I can > focus on it) and then it'd be easier to work on userland stuff in small > chunks of free time throughout the next school year. > > The reason I really want to work on Capsicum is because it addresses my > primary concern with OpenBSD: the poor availability of post-exploit > mitigation techniques, especially post-parallelism with sysjail. I > haven't completely bought into what appears to me to be Robert Watson's > greater vision of a realistic transition path towards > capability-oriented operating systems, I mostly just want to improve the > tools I use every day. > Great ! -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
