Comment 17 for bug 1663157

> I also did a bit of experimenting with adding "AppArmorProfile=/usr/lib/lightdm/lightdm-guest-session" to the bottom of /lib/systemd/system/user@.service

That was my first thought, too. This can be be done like this:

1) lightdm creates the temporary guest user/id.
2) lightdm then creates /run/systemd/system/user@${GUEST_UID}.service.d/lightdm.conf with

[Service]
AppArmorProfile=/usr/lib/lightdm/lightdm-guest-session

so that it applies *only* to the guest UID.

3) lightdm calls org.freedesktop.systemd1.Manager.Reload() (i. e. systemctl daemon-reload)
4) lightdm then goes on with starting the session
5) after the session finishes, clean up the above drop-in.

I tested that with a permanent user (as I don't want to change the lightdm code for experimentation), and I now get violations like

audit: type=1400 audit(1494448667.005:30): apparmor="DENIED" operation="sendmsg" profile="/usr/lib/lightdm/lightdm-guest-session" name="/run/systemd/journal/socket" pid=3252 comm="systemd" requested_mask="w" denied_mask="w" fsuid=1001 ouid=0
audit: type=1400 audit(1494448667.005:34): apparmor="DENIED" operation="open" profile="/usr/lib/lightdm/lightdm-guest-session" name="/proc/sys/kernel/cap_last_cap" pid=3252 comm="systemd" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
audit: type=1400 audit(1494448667.005:35): apparmor="DENIED" operation="mkdir" profile="/usr/lib/lightdm/lightdm-guest-session" name="/sys/fs/cgroup/systemd/user.slice/user-1001.slice/user@1001.service/init.scope/" pid=3252 comm="systemd" requested_mask="c" denied_mask="c" fsuid=1001 ouid=1001

As Tyler mentioned, the profile needs updating for a systemd user session, as that now confines each service into its own cgroup. Some stuff like reading cap_last_cap (the second violation) can probably just be quiesced, and maybe it can even disallow journal access, but access to the cgroup fs for and beneath user-$ID.slice is required if you want to use a systemd session for the guest session at all. The normal ACLs should already provide sufficient isolation there.

There is an alternative for SRUs: don't use the systemd user session but the upstart one. This requires adding an upstart dependency/recommends to lightdm, and use a different session than /usr/share/xsessions/ubuntu.desktop (which runs run-systemd-session) and use an upstart-y one instead. But at least for devel I think the above approach with a drop-in for AppArmorProfile= is better.