Kees and I discussed this today, so I will summarize the conversation (keep in mind I have not reviewed the code personally and Kees only performed a shallow audit):
* Size and scope: nova is a very large and complex piece of software with many daemons listening on the network and there is too much code to audit in any depth in time for this MIR. It would take significant resources to thoroughly audit the code * Upstream: very active, good community, and concerned about security with code that is of good quality, relatively easy to read and audit with authentication and security as part of the design * Frontend: APIs seem generally ok * Backend: way too much access via sudoers. If there is a security vulnerability that allows shell access as the nova user, then that user can become root easily in various ways. The best path to fixing this is adjusting the 40+ commands to be wrapped, and have this wrapper rigorously verify its input. Eg, instead of 'chown' in sudoers, use 'nova-wrap chown', then 'nova-wrap' verifies the paths to chown to ensure that it is modifying only the files it is supposed to. It would be even better if 'nova-wrap' was also then confined via AppArmor so there is MAC enforcement for these file accesses. Verifying access to network interfaces and items not associated with the filesystem also should be done. As an intermediate step, regexes could be used for file access in sudoers (but be wary of symlink bypasses) with 'nova-wrap' only being used for things like 'ip', 'ifconfig', etc, but it is the opinion of the security team that all privileged commands should be wrapped with extensive input validation, especially in time for 12.04. At this point it might be worthwhile to look at what nova is replacing (Eucalyptus) and how it compares since Eucalyptus used to be in main (it should be noted that the security team was not part of the MIR process for Eucalyptus). Nova compares favorably to Eucalyptus in terms of code quality, design, auditability and design. Nova currently suffers the same 'sudoers problem' as Eucalyptus, but I understand work is being done to fix this. All that said, the security team is not prepared to sign off on nova's inclusion in main if we are expected to support it alone. If there are upstream commitments and commitments from the Ubuntu Server team to aid in its support, then it seems 'ok enough' to promote at this time. As nova is a new project, I have concerns about these commitments with our older releases (eg, supporting the version of nova released with 12.04 in 2016). Could someone from the MIR team other than Kees make the decision to promote Nova or not? Kees has a conflict of interest since there is no clear security sign off from our team at this time. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/801501 Title: [MIR] nova To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/801501/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
