On 08/13/2012 05:32 PM, Aaron Weitekamp wrote: > On 08/13/2012 04:33 PM, Mo Morsi wrote: >> I created a feature in redmine to track the remaining work on the >> security backlog generated from the last audit. It can be found here: >> >> https://www.aeolusproject.org/redmine/issues/3693 >> >> By this point the process should be fairly established, the remaining >> work is largely a continuation / repetition of the work already done to >> cover the remaining controllers / models (plus a few specific things >> that need to be taken care of). The patches that have been pushed to the >> codebase so far should serve as a good example on how to proceed on this >> front. >> >> As always I'm looking for assistance w/ the security backlog so things >> move along faster. Appreciate it. >> >> -Mo >> > This is timely. From an integration QE perspective I'm developing > plans to test CloudForms vulnerabilities as a system. I was just going > to reach out to the list to determine what has been done. I believe > our approach will include some black box pen testing but I don't know > where the priorities are. > > I'm reviewing the wiki page on hardening the app and related links.[1] > This is good to see! Do you know what, if any, security testing is > planned outside of this? > > I would enjoy working with anyone who has an interest in this effort. > Thanks! > > > [1] > https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Hardening_the_app
Great! Appreciate the assistance. Up to this point the main focus has been on tightening up the Conductor webapp as thats the main entry point into the application. Other components including imagefactory and deltacloud could be looked at as well but in a full installation those aren't primarily user facing, and they should be able to be run in their own chroot'd sandboxes limiting possible attack vectors. With conductor I went through and audited the 0.4.0 release, comparing / contasting it against the rails best practices and general ruby coding guidelines. We've been using the wiki to track the progress and submitting patches in sets to the mailing list. The controller update is primarily done though more work needs to be done on the model side (including resolving any mass assignment vulnerabilities [1]). A diff would need to be done between the tagged release and the latest one to analyse recent additions. Maros has also been looking at integrating the best practices gem but not sure what the progress is on that. Last I heard there were some issues with running it on Fedora but those may have been resolved. Once that is working, I would like to leverage it and other ruby code metric tools to automate some of this security work. As far as work that needs tbd, tightening up the remaining tasks from the audit and integrating those tools in are of relative high priority. I would also like / having been pushing to get some infrastructure to host this so people can hammer on it. Any help on these fronts or anything in the general security / code quality direction would be more than appreciated, think we should be able to do something cool! -Mo [1] https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-July/011770.html
