Comment 3 for bug 961344

MAAS aims to provide an easy to use system for provisioning bare metal servers like how cloud providers provision virtual servers. At this point in time, it is able to do a number of things, but is not complete. At my review there was little usable documentation and MAAS is still undergoing a lot of development. I did not perform extensive code auditing since MAAS is undergoing a lot of change and will continue to do so during the 12.04 lifecycle. This should be considered a shallow audit. Understandably at its early stages of development, there are a lot of bugs that I encountered that affected usability. On quality and usability, there are a number of problems that prevent me from endorsing it for main in its present state, but understanding that MAAS is strategic, undergoing active development and will receive substantial bug fixes and features in the 12.04 cycle, I will have to take it on faith that these issues will be addressed. That said, I have the utmost confidence that the server team will fix the current issues and any new issues that arise.

The basic architecture is that a MAAS server is installed. This installs (among other things) a webserver, dns, tftp, and dhcp services. MAAS maintains a database of nodes. A node corresponds to a machine and MAAS tracks a machine's MAC address and few other characteristics. MAAS has a superuser which is capable of adding nodes, users and setting preferences via the web ui. Non-admin users are used by people who want to provision machines (eg, someone using the maas provider in juju must have a corresponding user in MAAS). Non-admin users are able to add nodes, but their enlistment must be approved by an admin user. Nodes can also auto-enlist themselves via the server installer CD (which also must be approved by the admin). When a node starts, it PXE boots using small netboot iso images that are available after using maas-import-isos (via cobbler). After booting the image, package installation for the node happens over the network and packages are fetched from a caching proxy (squid-deb-proxy). After a node is brought up, it is shown in MAAS as being allocated to a specific user. It is important to note that nodes must first be added to (or enlisted in) MAAS before trying to PXE boot a machine. This can happen either by a human in the web ui or by installation media.

MAAS has a lot of dependencies that affect the security of the server and performing an 'apt-get install maas' results in the following open ports:
- apache (80, privilege-separated)
- squid (8000, acls should keep this safe, non-root)
- dnsmasq (53, 67, non-root)
- sshd (standard Ubuntu priv-separation)
- postgres (localhost:5432)
- mass-pserv (5241, runs as root)
- maas-txlongpoll (5242, runs as root)
- epmd (4369, non-root)
- rabbitmq (non-root)
- rsyslog (udp 514, non-root)
- tftpd (69, privilege-separated)
- cobbler (localhost:25151, root)

In using this with juju, it appears that the server really only needs to have the following ports open to the nodes on the LAN:
- apache (80)
- squid (8000)
- dnsmasq (53, 67)
- tftpd (69)
- rsyslog (udp 514)

Because MAAS uses MAC addresses (which are easily spoofed), dhcp and tftp for initial provisioning, and traditional 514/udp syslog, the MAAS server and nodes need to reside on a trusted network.

For client usability (eg, juju), MAAS was spotty. Using it as a juju provider had to be done in a very particular undocumented sequence of steps to work at all, and even then I was only able to get the juju bootstrapping node to work reasonably well (though not bug-free). There is a maas cli tool that is being written, but it is not merged yet so it was not reviewed.

The web interface was attractive and easy to navigate, though I found layout and spelling errors (eg 'After commissionning' in 'Add node') and I still don't know what the three options mean after commissioning. MAAS defaulted to adding '.local' to the hostname, but the documented configuration for dnsmasq does not allow for avahi integration (and maas-dhcp doesn't seem to configure this right either). As such nodes are unreachable by juju (but are reachable after stripping '.local'). There were also issues with ssh keys being copied over after using 'juju deploy' even though I followed the same (undocumented) sequence of commands I did to get the bootstrapping node going. It is possible this was due to my environment.

Examining the nodes themselves after provisioning:
- like Ubuntu's work with EC2 and OpenStack, an 'ubuntu' user is added to each node. This user has a disabled password and has passwordless admin access via sudo. After successful provisioning, ssh keys for the user are added to that user's allocated nodes. SSH logins are then permitted to the 'ubuntu' user. The 'root' user is also allowed, but an ssh forced command is in place to prevent its use. This is acceptable.
- PXE booting a node and examining it after install shows that nodes are standard Ubuntu server installs with openssh-server and cloud-init
- No firewall rules are added to the nodes, like might be expected with EC2 security groups. This is another reason for only deploying MAAS in trusted environments-- site policies may require nodes to be configured more securely before exposing an ssh server to the world

In terms of code:
- the web ui uses django (good):
  - forms are using django's csrfmiddlewaretoken
  - django has sql injection protections, et al
  - resistant to XSS attacks (spot checked)
  - various forms were spot checked and did input validation (particularly where a user could input data the admin could view)
- there is a lot of hardcoded 'http://%s' code which means that MAAS is cannot be easily converted to use SSL. This means that accessing the web interface
over the internet is insecure. Login credentials are easily seen on the wire.
- MAAS currently relies on cobbler. Thankfully it is only listening on the loopback interface and that it is written in python, but it runs as root and even the most cursory inspection of code shows that parts of it are not coded well (eg, use of 'os.system', predictable filenames, etc).
- yui is embedded in MAAS. Why not use the system yui? yui had 4 vulnerabilities (all XSS) in 2010. Debian/Ubuntu have yui 2.8.2 and maas is using 3.4.1. There are no open vulnerabilities
- raphael is embedded in MAAS. There are no open vulnerabilities. Debian/Ubuntu have 2.0.1 and MAAS uses 2.1.0.

In terms of packaging:
- maas is not lintian clean
- two root running network daemons are provided (maas-pserv and
  maas-txlongpoll)
- there are no setuid binaries or dbus services
- it ships 3 cron jobs:
 * mass-gc (garbage collector-- undocumented)
 * maas-import-isos: grabs new isos via maas-import-isos
 * maas_remote_syslog_compress: compresses logs. Potentially noisy: 'bzip2: Input file ... already has .bz2 suffix.'

Recommendations:
Since maas was prepromoted, in the interest of time and ensuring these are tracked and fixed, I have filed bugs for each of these items and targeted them towards either 12.04 or precise-updates.

- for 12.04, add comments to cron jobs for what they do. eg, "Runs 'maas gc' every day at midnight" is not very helpful for someone who doesn't know what 'gc' is (LP: #975435)
- for 12.04, if possible run mass-pserv and maas-txlongpoll as non-root (LP: #975436)
- for 12.04, add an apparmor profile for /usr/bin/cobblerd. This can be in the maas packaging (eg, maas-cobbler?) since maas hides the cobbler configuration from the user and therefore the profile can be tailored specifically for maas (LP: #975442)
- For 12.04, bind all services not required by the nodes to the loopback interface (like with postgresql). This includes mass-pserv, maas-txlongpoll, epmd, and rabbitmq and anything else that is added. If this cannot be done, add explict firewall rules (I suggest in a 'maas' chain to make this play nice with other rulesets) for these open ports (LP: #975450)
- for 12.04 add some preliminary documentation and man pages. This could be an extremely high level overview with links to official documentation. This must also document that the maas server and its nodes must be on a trusted network. Accessing the maas server over the internet should be considered insecure due to lack of SSL. This should be part of the release notes. (LP: #975452)
- for 12.04.1, finish documentation and man pages. I found it difficult to use and error prone on its own. A 'man maas' page would be good with high-level concepts described (eg, the topology, how to interact with MAAS, the order to do things). A brief tutorial would be good as well. This does not have to be a lot of text, but at least something so people can understand it. (LP: #975454)
- By 12.04.1, add at least of the capability of using https://<server>/MAAS if people want to use it. (LP: #975462)
- For 12.04, clearly document that nodes are brought up without firewall rules or security group in place. (LP: #975464)
- For 12.04.1 consider implementing a 'security group' functionality (LP: #975468)
- By 12.04.1 supply high level design/security document(s) (LP: #975472)
- For 12.04.1, eliminate the cobbler dependency (LP: #975473)