On Thu, Mar 13, 2014 at 10:08 AM, Jean-Philippe Ouellet <[email protected]> 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/[email protected]/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.
