Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 11:15 PM, Loganaden Velvindron wrote: 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. Yep, I consider it as an incremental improvement, not a complete solution. 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. I plan to build a src/regress/sys/kern/capsicum as I implement various functionality, but as for other services and such, I'm not sure how best to go about formally testing that. For larger integration-test stuff I generally just throw all my experimental code on all my production boxes and watch what happens. The more people who use those services the better because if something is broken I'll find out earlier and I can fix it. That's also the impression I got of how the pre-release testing cycle seems to work here. Also, please look into FreeBSD's regression test suite for capsicum. I'm aware of: http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/ http://svnweb.freebsd.org/base/head/tools/regression/capsicum/ https://github.com/google/capsicum-test is there something else? Good testing coverage is also very important Agreed. 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. I was going to wait until it's at a usable state before I solicit effort from others, otherwise it's just pointless discussion, but yes, that's the plan. In the mean time, I'll just shut up and hack. The patches will probably be peer reviewed by many people, as capsicum touches different areas of the kernel. This process will take time. Naturally. I'd expect nothing less! :)
Re: GSoC proposal: Porting Capsicum to OpenBSD
On Thu, Mar 13, 2014 at 10:08 AM, Jean-Philippe Ouellet jean-phili...@ouellet.biz wrote: On 3/12/14 11:15 PM, Loganaden Velvindron wrote: 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. Yep, I consider it as an incremental improvement, not a complete solution. 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. I plan to build a src/regress/sys/kern/capsicum as I implement various functionality, but as for other services and such, I'm not sure how best to go about formally testing that. For larger integration-test stuff I generally just throw all my experimental code on all my production boxes and watch what happens. The more people who use those services the better because if something is broken I'll find out earlier and I can fix it. That's also the impression I got of how the pre-release testing cycle seems to work here. I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Also, it will probably help to contact the port maintainers as well, and ask them to test the capsicum diffs, to make sure that we don't end up with things like unbound crashing on OpenBSD. Also, please look into FreeBSD's regression test suite for capsicum. I'm aware of: http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/ http://svnweb.freebsd.org/base/head/tools/regression/capsicum/ https://github.com/google/capsicum-test is there something else? Those are what I'm aware as well. Good testing coverage is also very important Agreed. 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. I was going to wait until it's at a usable state before I solicit effort from others, otherwise it's just pointless discussion, but yes, that's the plan. In the mean time, I'll just shut up and hack. What I'm referring to here is that some developers are interested in capsicum, and others are less interested. If you plan on working on capsicum on say ntpd, then it would help to contact the maintainer of ntp and see if he's interested. If he is, then you can put it on your workplan for your gsoc. It doesn't help much if there is no interest in merging the code upstream IMHO. Please see this discussion for opensmtpd: https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html The patches will probably be peer reviewed by many people, as capsicum touches different areas of the kernel. This process will take time. Naturally. I'd expect nothing less! :) I hope that you will stick around after the gsoc :-) -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/13/14 2:39 AM, Loganaden Velvindron wrote: I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Any chance you'd like to review my bootloader patch from last month then? http://marc.info/?l=openbsd-techm=139408992902933 I still haven't gotten any feedback. What I'm referring to here is that some developers are interested in capsicum, and others are less interested. If you plan on working on capsicum on say ntpd, then it would help to contact the maintainer of ntp and see if he's interested. If he is, then you can put it on your workplan for your gsoc. It doesn't help much if there is no interest in merging the code upstream IMHO. Please see this discussion for opensmtpd: https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html I see. OpenNTPD was actually one of the services I hilighted as a potentially good candidate in the short proposal thing I submitted as google's requirement. I hope that you will stick around after the gsoc :-) Oh, I've been around a while, mostly just lurking, and I don't plan on going anywhere. The question is more about finding time to contribute.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On Thu, Mar 13, 2014 at 10:57 AM, Jean-Philippe Ouellet jean-phili...@ouellet.biz wrote: On 3/13/14 2:39 AM, Loganaden Velvindron wrote: I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Any chance you'd like to review my bootloader patch from last month then? I'm not a committer, but I can test your diff once I get back home. I have a sparc64 machine. It needs to powered on. Your best bet is asking a guy who hacks on Sparc64. Check out the commit logs to see who last hacked on that area. http://marc.info/?l=openbsd-techm=139408992902933 I still haven't gotten any feedback. What I'm referring to here is that some developers are interested in capsicum, and others are less interested. If you plan on working on capsicum on say ntpd, then it would help to contact the maintainer of ntp and see if he's interested. If he is, then you can put it on your workplan for your gsoc. It doesn't help much if there is no interest in merging the code upstream IMHO. Please see this discussion for opensmtpd: https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html I see. OpenNTPD was actually one of the services I hilighted as a potentially good candidate in the short proposal thing I submitted as google's requirement. Is that proposal available online ? I hope that you will stick around after the gsoc :-) Oh, I've been around a while, mostly just lurking, and I don't plan on going anywhere. The question is more about finding time to contribute. :-) -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: GSoC proposal: Porting Capsicum to OpenBSD
Wow, I like to see this activity. I'm the one that started this thread. Jean-Phillipe: The main problem we'll have if both of us work on this is that it won't not be possible to work on userland if the kernel doesn't yet provide capability mode. Also, I think that both of us working in this project is not a good idea (specially given that what I liked most of this idea is the fact of getting to know the OpenBSD kernel, and work with it at the low level). FWIW, some future work with this would be great, but only after having the basic Capsicum support in the kernel. It's either that, or having a competition, and I would rather be able to work on something else than having a silly competition for a job, specially when there's a lot of work to be done :) Loganaden, many thanks for the awesome email(s) you sent here. I already contacted the Implement clang/llvm static code checker mentor, and he is quite responsive, so it seems that I just have found my proposal for OpenBSD :) Many thanks to everyone, and I'm happy to see that from this thread has sprung some activity over here. 2014-03-12 22:01 GMT+01:00 Jean-Philippe Ouellet jean-phili...@ouellet.biz : 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. 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. There's also a ton of userland things besides daemons/services that could (probably should) be capsicumized. 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. 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. -- Daniel
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/13/14 3:18 AM, Loganaden Velvindron wrote: On 3/13/14 10:57 AM, Jean-Philippe Ouellet wrote: On 3/13/14 2:39 AM, Loganaden Velvindron wrote: I'm not a mentor, but I'd be happy to help you in any way I can. You can send mails to tech@ for testing your diffs. Any chance you'd like to review my bootloader patch from last month then? I'm not a committer, but I can test your diff once I get back home. I have a sparc64 machine. It needs to powered on. Your best bet is asking a guy who hacks on Sparc64. Check out the commit logs to see who last hacked on that area. Ofwboot hasn't had many substantive changes in years. There was the early entropy stuff, PIE stuff, and some minor cleanups, but otherwise it's just been left alone. (as it should IMO. it's minimal and that's what I want. I consider this patch to reduce the complexity of the required booting infrastructure in general, as it eliminates the need for more daemons and stuff on your lan.) I was wondering whether I should bug kettenis@ about it since AFAIK he's the main sparc64 guy, but the part that I think maybe should change before it's considered for OKs is the ugly (although I'm pretty sure correct) NFS URL parsing code, which really anybody could look at as it isn't hardware-specific. Is it considered rude to bug specific people about patches? I assumed someone would step forward if they were interested, and if nobody was interested, then it didn't belong in the tree. I see. OpenNTPD was actually one of the services I hilighted as a potentially good candidate in the short proposal thing I submitted as google's requirement. Is that proposal available online ? No, but it didn't contain anything I haven't said in some form on tech@ by now anyway, except for the Provide a schedule estimate with dates and important milestones in two week increments. which I'm sure wasn't accurate anyway. signature.asc Description: OpenPGP digital signature
Re: GSoC proposal: Porting Capsicum to OpenBSD
On Thu, Mar 13, 2014 at 11:44 AM, dpl tucha...@gmail.com wrote: Wow, I like to see this activity. I'm the one that started this thread. Jean-Phillipe: The main problem we'll have if both of us work on this is that it won't not be possible to work on userland if the kernel doesn't yet provide capability mode. Also, I think that both of us working in this project is not a good idea (specially given that what I liked most of this idea is the fact of getting to know the OpenBSD kernel, and work with it at the low level). FWIW, some future work with this would be great, but only after having the basic Capsicum support in the kernel. It's either that, or having a competition, and I would rather be able to work on something else than having a silly competition for a job, specially when there's a lot of work to be done :) Loganaden, many thanks for the awesome email(s) you sent here. I already contacted the Implement clang/llvm static code checker mentor, and he is quite responsive, so it seems that I just have found my proposal for OpenBSD :) (Logan's fine) Great ! If you have friends in your university who are interested in OpenBSD and security stuff, please let them know about OpenBSD's GSOC for this year ! Many thanks to everyone, and I'm happy to see that from this thread has sprung some activity over here. You're welcome. 2014-03-12 22:01 GMT+01:00 Jean-Philippe Ouellet jean-phili...@ouellet.biz : 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. 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. There's also a ton of userland things besides daemons/services that could (probably should) be capsicumized. 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. 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. -- Daniel -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
GSoC proposal: Porting Capsicum to OpenBSD
Hi all, I'm really interested in this possibility of porting the Capsicum framework to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? Also, do we have any IRC channel to discuss al this? Many thanks,
Re: GSoC proposal: Porting Capsicum to OpenBSD
perhaps, you should try to send a message to the project mentors, as pointed out in the foundation/gsoc page: http://www.openbsdfoundation.org/gsoc2014.html#capsicum -a On Wed, Mar 12, 2014 at 09:58:24AM +0100, tuchalia wrote: Hi all, I'm really interested in this possibility of porting the Capsicum framework to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? Also, do we have any IRC channel to discuss al this? Many thanks,
Re: GSoC proposal: Porting Capsicum to OpenBSD
On Wed, Mar 12, 2014 at 12:58 PM, tuchalia tucha...@gmail.com wrote: Hi all, I'm really interested in this possibility of porting the Capsicum framework That's awesome ! to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? Capsicum is a huge project, and realistically, it's impossible to to port it completely and get a production grade version by working only 8-12 weeks. The project clearly exceeds the mandate of a GSoC, in my opinion. You might start by planning the kernel implementation, similar to what Joris did for DragonflyBSD. (http://leaf.dragonflybsd.org/mailarchive/kernel/2013-04/msg00025.html). With a kernel implementation, we can do quite a lot of things, like what happened for OpenSSH 6.5. OpenSSH 6.5 has capsicum support on FreeBSD, and it doesn't need casper to sandbox the pre-auth code. matthew had already started working on some bits. (https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2011-July/msg2.html) Your best bet is to speak to damien miller and work out a sensible plan. If you're really interested motivated in doing a good complete work, you should be ready to spend time after gsoc getting feedback on the diffs, and improve them. Personally, I would like to see a working kernel implementation, and getting at least sshd in base capsicumised :-) I can help you with the last part, as I'm familiar with the code. Please talk to damien matthew as they might have a different roadmap or radically different ideas in mind. I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). Very good ! However, I would advise caution here, as there has been at least one bug that has been reported with the changes happening in FreeBSD. (http://unbound.net/pipermail/unbound-users/2014-February/003169.html). So you have to be prepared to fix any potential fallout if capsicum port is to be merged into OpenBSD :-) I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? I would advise you to look into Joris's posts to DragonflyBSD lists, and see what difficulties he faced when he ported capsicum to dflybsd. Also, please take into account that OpenBSD kernel is different from FreeBSD kernel, and that will probably involve a lot of rewriting. You are lucky as OpenBSD has a rock solid -current tree. Ideally, you would have a dedicated physical box such as a 2nd laptop or a development machine to work on that IMHO. Read the OpenBSD FAQ for running -current. http://www.openbsd.org/faq/current.html Also, do we have any IRC channel to discuss al this? I'll send it to you in a personal mail. Many thanks, Good luck with your proposal ! -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 4:58 AM, tuchalia wrote: Hi all, I'm really interested in this possibility of porting the Capsicum framework to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? Also, do we have any IRC channel to discuss al this? Many thanks, I'm also interested in porting Capsicum, although so far all my emails about it have been off-list. I've already been in contact with dempsky@ (one of the listed mentors, and has previously done some work towards porting it) since before the OpenBSD Foundation announced it was applying for GSoC, and I submitted my application to Google when applications opened on the 10th. Hopefully I'll get accepted. If we both get accepted I think that could work well too, there's certainly enough work to do. We should just plan out what exactly we're each going to do to avoid stepping on each others' toes too much. Thankfully the API is already well defined thanks to FreeBSD so cooperating on different parts should be pretty easy, and it'd be nice to have another dedicated person to peer-review patches with.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On 3/12/14 4:58 AM, tuchalia wrote: Also, do we have any IRC channel to discuss al this? I've been wondering about that too, although I was never really active on any of the channels. Mindcry is dead, subcult is mostly non-english, freenode and efnet are mostly whiners. I vaguely remember something about silc, but if the unmaintained client is anything to judge by, that's dead now too. I don't mean to intrude, but I am curious where things happen now.
Re: GSoC proposal: Porting Capsicum to OpenBSD
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. 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. There's also a ton of userland things besides daemons/services that could (probably should) be capsicumized. 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. 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.
Re: GSoC proposal: Porting Capsicum to OpenBSD
On Wed, Mar 12, 2014 at 10:49 PM, Jean-Philippe Ouellet jean-phili...@ouellet.biz wrote: On 3/12/14 4:58 AM, tuchalia wrote: Hi all, I'm really interested in this possibility of porting the Capsicum framework to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or only work in the kernel implementation? I've used Capsicum during the last summer, but I only worked with the syscall API, that is, no Casper (something that can be fixed quickly). I know what I should I do with the Capsicum side (in the matter of getting some info to have a strong proposal) but I'm not sure about where to look when it comes to the OpenBSD side. Should I take a look at the process data structure, and how all this is implemented in the kernel? Should I take a look somewhere else? Also, do we have any IRC channel to discuss al this? Many thanks, I'm also interested in porting Capsicum, although so far all my emails about it have been off-list. I've already been in contact with dempsky@ (one of the listed mentors, and has previously done some work towards porting it) since before the OpenBSD Foundation announced it was applying for GSoC, and I submitted my application to Google when applications opened on the 10th. Hopefully I'll get accepted. Great ! If we both get accepted I think that could work well too, there's certainly enough work to do. We should just plan out what exactly we're each going to do to avoid stepping on each others' toes too much. Thankfully the API is already well defined thanks to FreeBSD so cooperating on different parts should be pretty easy, and it'd be nice to have another dedicated person to peer-review patches with. If both of you are planning to work on capsicum, please consider making both of your work plans available so that mentors can help you split the work. The patches will probably be peer reviewed by many people, as capsicum touches different areas of the kernel. This process will take time. -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: GSoC proposal: Porting Capsicum to OpenBSD
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/msg0.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.
