Guest session processes are not confined in 16.10 and newer releases

After coming back to this bug, I noticed that Robert was not subscribed and couldn't see the bug. He's now subscribed.

The pstree output helps shed some light on this bug. It looks like the portions of the guest session that are spawned upstart are properly confined. The portions spawned by systemd are not confined. I'm attaching the `pstree -Z guest-XXXXXX` output from a running yakkety guest session.

Here's the pstree output for a zesty system. It looks like more things have been moved over to systemd's control and, therefore, more things are unconfined.

I should mention that the above pstree outputs require some changes to the pstree code to get the AppArmor label included in the output when the -Z option is specified. I've pushed a work-in-progress quality git branch of psmisc to https://code.launchpad.net/~tyhicks/psmisc/+git/psmisc/+ref/apparmor that includes the necessary changes.

Ow. Unfortunately I don't have any information on how to fix this since most of the work on guest sessions and systemd was done by Martin Pitt.

@pitti - I know you don't have any responsibility here but wondering if you have any advice on what direction to solve this?

The proper way to do this would be to use pam_apparmor, similar to how selinux is doing this, through systemd --user
  /etc/pam.d/systemd-user

However currently this would require updating to a new version of pam_apparmor OR confining systemd to define hats and potentially other setup, which is probably something we are not ready to do just yet.

Note: ideally we want to set things up to use a policy namespace stack so that snaps can work from the guest session.

I spent some time looking into pam_apparmor and understanding how could be used. It seems like it would be extremely risky to introduce in a security update and I'm not sure if it even supports everything that would be needed. IIUC, it requires us to confine all login applications that use PAM and it isn't clear if we can selectively confine only the guest users and leave all other users unconfined. At this point, I'm not comfortable/confident in pam_apparmor as a solution in stable release.

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 and logging in via a guest session in LightDM. After some scary lightdm-guest-session profile updates, I was able to log in to the guest session. The scary permissions are required because `systemd --user` is being confined by the lightdm-guest-session profile so rules are needed to allow all of the session setup stuff that it does. That's not promising because then all of those permissions will be granted to the guest session itself. I don't see a way to get `systemd --user` to transition to another profile when launching processes inside of the session but I could be missing something.

Modifying the user@.service file also isn't ideal because I don't see a way to only apply the AppArmor profile to guest user sessions while leaving regular user sessions unconfined.

I don't see a good solution to this problem.

@tyhicks you are correct that pam_apparmor is NOT a good solution currently. I will restate, it requires either
- a new version of pam_apparmor
or
- confining systemd and setting up hats for the guest session user (which currently means the user name can not have randomization).

pam_apparmor does NOT require we confine all pam applications, just those that are using it.

A minimal patch to better support guest sessions in pam_apparmor (using change_onexec instead of change_hat) could be done (again basically a new version of pam_apparmor), and might be the best solution. Or if you want I guess we could look at landing full support but that is larger and would involve the parser, etc.

We need to either find a solution to this issue, or push an update to disable guest sessions.

FWIW - Desktop are fine with disabling the guest session while we work out the systemd stuff.

Patch to Yakkety that disables guest support by default.

Patch to Zesty that disables guest support by default.

These patches ship LightDM with guest support disabled by default. You can re-enable it by putting a config file with higher priority containing:

[Seat:*]
allow-guest=true

e.g. put this in:

/etc/lightdm/lightdm.conf (if editing manually)
/etc/lightdm/lightdm.conf.d/enable-guest.conf (if managing with snippets)
/usr/share/lightdm/lightdm.conf.d/99-enable-guest.conf (if shipping in a package)

@robert-ancell thanks for the debdiffs! Is the addition of debian/99-disable-guest.conf intentional in the zesty debdiff? I suspect that debian/50-disable-guest.conf is sufficient and that 99-disable-guest.conf was meant to be removed.

> 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.

@Tyler - yes, the 99 should have been removed...

Fixed zesty debdiff

This is CVE-2017-8900.

This bug was fixed in the package lightdm - 1.19.5-0ubuntu1.2

---------------
lightdm (1.19.5-0ubuntu1.2) yakkety-security; urgency=medium

  * SECURITY UPDATE: Guest session not confined (LP: #1663157)
    - debian/50-disable-guest.conf:
    - debian/lightdm.install:
      - Disable guest sessions by default, this can be overridden by custom
        configuration (e.g. /etc/lightdm/lightdm.conf)
    - CVE-2017-8900

 -- Robert Ancell <email address hidden> Tue, 09 May 2017 09:32:16 +1200

This bug was fixed in the package lightdm - 1.22.0-0ubuntu2.1

---------------
lightdm (1.22.0-0ubuntu2.1) zesty-security; urgency=medium

  * SECURITY UPDATE: Guest session not confined (LP: #1663157)
    - debian/50-disable-guest.conf:
    - debian/lightdm.install:
      - Disable guest sessions by default, this can be overridden by custom
        configuration (e.g. /etc/lightdm/lightdm.conf)
    - CVE-2017-8900

 -- Robert Ancell <email address hidden> Tue, 09 May 2017 09:32:16 +1200

I'm making this bug public now that we have security updates published which disable the guest session. My hope is that we can re-enable it after the changes suggested by pitti can be investigated/implemented.

If you have a use case which requires the guest session, you can manually re-enable it by writing the following contents to /etc/lightdm/lightdm.conf:

# Manually enable guest sessions despite them not being confined
# IMPORTANT: Makes the system vulnerable to CVE-2017-8900
# https://bugs.launchpad.net/bugs/1663157
[Seat:*]
allow-guest=true

Balint, could you follow through on this bug? Martin has provided some good general guidance already about what's required to re-enable secure guest sessions in artful.

This bug was fixed in the package lightdm - 1.22.0-0ubuntu4

---------------
lightdm (1.22.0-0ubuntu4) artful; urgency=medium

  * SECURITY UPDATE: Guest session not confined (LP: #1663157)
    - debian/50-disable-guest.conf:
    - debian/lightdm.install:
      - Disable guest sessions by default, this can be overridden by custom
        configuration (e.g. /etc/lightdm/lightdm.conf)
    - CVE-2017-8900

 -- Robert Ancell <email address hidden> Mon, 19 Jun 2017 16:32:24 +1200

Hey guys I am a newbie to linux and I am coming from windows...I just want to have that button on my login screen or somewhere on the notification zone ...everything you have explained is hard for me to understand can you please elaborate it in steps ..so that I enable guest-session on my computer?

@Magezi: Please note that this is a bug report, not a support forum. This Ask Ubuntu question may help:

https://askubuntu.com/q/915415

Reopening, since the guest session is disabled by default but it is still not confined.

@rbalint can you please open a new bug to track re-enabling the guest session with proper confinement rather than piggy back on this bug?

@tyhicks I just opened LP #1742912 for tracking the confinement fix.