Security review: After performing a shallow, high-level code audit: - There is one python script and no dbus services, setuid capabilities, fscaps or cron jobs. But there are security relevant items to note: - Ubuntu patches wagent to add an upstart job via '--setup' that runs the agent as a daemon as root. '--setup' is run during postinst - When creating an account (happens during specific state changes), it creates /etc/sudoers.d/waagent. If the the uid of the user is < UID_MIN from /etc/login.defs, it adds NOPASSWD to the entry in /etc/sudoers.d/waagent. This could be a problem if someone with a UID of 999 creates an account but in all other ways is a non-system user. I'm not sure if it makes sense to have a system user added, so maybe this NOPASSWD bit can be patched out? - /etc/sudoers.d/waagent is unconditionally deleted on account removal, meaning if multiple accounts were added via waagent, any other accounts likely are broken - Run() is implemented as 'os.system()' with no input filtering. This is not good because shell injection attacks can be performed if the input to os.system() is user controllable. Run() should be converted to use subprocess.Popen(). Based on ovfobj = OvfEnv().Parse(ovfxml) from the Agent class, this means anything on the DVD could do bad stuff-- though we must expect the DVD to be trusted. Run() is also used extensively via the HostingEnvironmentConfig. I don't consider this a security issue in and of itself (the agent necessarily trusts the server and DVD), but it would be good to use subprocess.Popen() as a hardening measure. - Will start up a server LoadBalancerProbeServer() that runs a simple SocketServer.TCPServer(). This server just returns the date and time, and load balances its log. Adding an iptables rule to only allow access to this port from the fabric controller may be a useful hardening measure. - DoDhcpWork() unconditionally opens port 68/udp (dhcp client) on the firewall in the INPUT chain, then makes a dhcp request - In general, waagent uses a poll architecture (http://www.faqs.org/patents/imgfull/20120102186_04), where the agent periodically asked the Endpoint for things to do. This is fine so long as the server can be trusted. It might be worthwhile to add an egress rule so the agent can only talk to the fabric controller on th e defined port for the fabric controller.
In all, while the code is running as root, there is only one listening service and it is extremely simple. As mentioned, adding ingress filtering for this service is recommended, but not a condition of this MIR. waagent touches large parts of the system, but that is what it is designed to do. While I do have some reservations based on my findings and the newness of the code, it sounds like this will be well maintained in Ubuntu since several people from Canonical have stepped up to maintain it. ACK from the security team. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1014864 Title: [MIR] walinuxagent To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1014864/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
