Thank you for using Ubuntu and reporting a bug.

The initial title for this bug is misleading: "Bypass AppArmor ruleset of MySQL allows for remote code execution". First, the MySQL profile does not allow MySQL to execute code in /tmp or other places and none of the profile's ruleset was bypassed. As you said, it does allow writing files to /tmp (see below for possible improvements). Second, Ubuntu does not ship a profile for apache, php or phpnuke. While there is an example profile for phpsysinfo (that is in complain mode), it does not use the user-tmp abstraction. Third, the attack relies upon php being able to include a file from /tmp. This should be considered a broken php configuration.

That said, this bug does make a good point: administrators creating AppArmor profiles and configuring their systems need to be mindful of interactions between applications. As demonstrated, AppArmor can both be configured to prevent attacks in vulnerable applications as well as misconfigured to allow said attacks.

As described, there are several things which could help prevent this attack from succeeding, remembering that mysql runs as the 'mysql' user and apache runs as the 'www-data' user in Ubuntu:
1. include_path could be used to disallow including files from /tmp. Because of the wide range of applications that user's can install, Ubuntu cannot ship with a hardened include_path, but it should be considered standard/best practice to adjust this for precisely the bug you mentioned. Also, DAC should have prevented writing to /var/www in the first place (though by your description, AppArmor caught it first).
2. as mentioned, MySQL could be configured to use a different tmp directory with mode 700, then normal DAC would have prevented this attack. This can be done by adjusting the 'tmpdir' variable in mysql.cnf. This should be considered for inclusion in Ubuntu.
3. a umask of 077 could be used for MySQL in which case normal DAC would have prevented this. This should be considered for inclusion in Ubuntu
4. the php application could have been protected with AppArmor, disallowing reads from /tmp

I do consider it a bug that the LAMP stack is allowed to interact in this manner. MySQL does need a temporary directory to do its work, and the problem is not in AppArmor (we can't deny access to MySQL's scratch area without breaking it) but in the default configuration for MySQL in Ubuntu. Adjusting MySQL's umask to 077 is probably the simplest and safest change that could be made, and would have prevented this attack.

I am going to open a task against mysql for 2 and 3 above. I do not believe this is a bug in AppArmor because, as mentioned, it is simply allowing the necessary access to MySQL's scratch area and Ubuntu does not ship a profile for this vulnerable php application, apache or php (if an administrator writes one, then it is the administrator's responsibility to understand the interactions between the software in use on his/her system).

That said, I am going to leave the apparmor task open for now, because one improvement could be considered in the user-tmp abstraction: we could use an owner match. If both MySQL and the php application were confined by AppArmor and both used the user-tmp abstraction with this owner match, then AppArmor could have prevented against the (mis)configuration of mysql and the vulnerable php application. This improvement needs to be carefully considered, because it might break other applications, but it would be useful in helping prevent against combined attacks when all the software is confined by AppArmor.