"Remote Login" account not confined by guest AppArmor profile

How to reproduce:

- Guest account:
  - open session
  - open terminal
  - "cd /home;ls" should give "Permission denied" and dmesg should show AppArmor denial

- Remote Login:
  - Click on Remote Login help icon in greeter
  - Click on "Set up" button
  - open terminal
  - "cd /home;ls" should fail, but currently does not.

The way AppArmour profiles are applied in lightdm is based on the session process name. So in the case of the guest session lightdm runs /usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper which then runs the actual session process (e.g. gnome-session). The binary name "/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" is matched in the AppArmor profile /etc/apparmor.d/lightdm-guest-session.

For remote sessions lightdm doesn't run it through the guest wrapper so no AppArmor profile is applied by default. We could run it through the same wrapper but remote sessions probably want an even more restrictive profile (there should be no access to the local filesystem at all).

So in short, I think the packages lightdm-remote-session-freerdp and lightdm-remote-session-uccsconfigure packages should provide AppArmor profiles for /usr/lib/x86_64-linux-gnu/lightdm-remote-session-freerdp/freerdp-session and /usr/share/lightdm-remote-session-uccsconfigure/uccsconfigure-session.

This is about the limit of my knowledge of AppArmor - for more information ask Martin Pitt as he implemented this feature.

Thinking over this has made me rethink how guest sessions are implemented in LightDM. The AppArmor code has always been an awkward fit in the daemon (which can't possibly know what resources a session will require). I propose for LightDM 1.6 that the guest sessions are externally defined with their own AppArmor profiles like the proposal for remote sessions is done (bug 1050739).

The downside of all this is each session requires its own AppArmor profile which will probably all be quite similar. I don't know if AppArmour has any support for simplifying this.

This bug was fixed in the package lightdm-remote-session-freerdp - 1.0-0ubuntu1

---------------
lightdm-remote-session-freerdp (1.0-0ubuntu1) quantal; urgency=low

  * New upstream release.
    * Adding apparmor wrapper to ensure protection (LP: #1049849)
  * debian/control:
    * Add depends on Apparmor
  * debian/rules: Add installing of apparmor profile
 -- Ted Gould <email address hidden> Wed, 19 Sep 2012 13:58:41 -0500

This bug was fixed in the package lightdm-remote-session-uccsconfigure - 1.1-0ubuntu1

---------------
lightdm-remote-session-uccsconfigure (1.1-0ubuntu1) quantal; urgency=low

  * New upstream release.
    * Adding apparmor wrappers (LP: #1049849)
  * debian/control:
    * Going to arch any as we have a binary now
    * Adding dh_apparmor and suggests apparmor
  * debian/rules:
    * Adding apparmor build rules
 -- Ted Gould <email address hidden> Wed, 19 Sep 2012 13:53:16 -0500