Guest session processes are not confined in 16.10 and newer releases

[Tyler Hicks]

Processes launched under a lightdm guest session are not confined by the /usr/lib/lightdm/lightdm-guest-session AppArmor profile in Ubuntu 16.10, Ubuntu 17.04, and Ubuntu Artful (current dev release). The processes are unconfined.

The simple test case is to log into a guest session, launch a terminal with ctrl-alt-t, and run the following command:

 $ cat /proc/self/attr/current

Expected output, as seen in Ubuntu 16.04 LTS, is:

 /usr/lib/lightdm/lightdm-guest-session (enforce)

Running the command inside of an Ubuntu 16.10 and newer guest session results in:

 unconfined

[Tyler Hicks (tyhicks)]

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

[Tyler Hicks (tyhicks)]

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.

[Tyler Hicks (tyhicks)]

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.

[Tyler Hicks (tyhicks)]

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.

[Robert Ancell (robert-ancell)]

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.

[Robert Ancell (robert-ancell)]

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

[John Johansen (jjohansen)]

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.

[John Johansen (jjohansen)]

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

[Tyler Hicks (tyhicks)]

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.

[John Johansen (jjohansen)]

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

[Marc Deslauriers (mdeslaur)]

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

[Will Cooke (willcooke)]

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

[Robert Ancell (robert-ancell)]

Patch to Yakkety that disables guest support by default.

[Robert Ancell (robert-ancell)]

Patch to Zesty that disables guest support by default.

[Robert Ancell (robert-ancell)]

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)

[Tyler Hicks (tyhicks)]

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

[Martin Pitt (pitti)]

> 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/[e-mail]/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.

[Robert Ancell (robert-ancell)]

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

[Robert Ancell (robert-ancell)]

Fixed zesty debdiff

[Tyler Hicks (tyhicks)]

This is CVE-2017-8900.

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Tyler Hicks (tyhicks)]

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.

[Tyler Hicks (tyhicks)]

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

[Steve Langasek (vorlon)]

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.

[Launchpad Janitor (janitor)]

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

[Magezi Sagesse (magezi)]

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?

[Gunnar Hjalmarsson (gunnarhj)]

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

https://askubuntu.com/q/915415

[Balint Reczey (rbalint)]

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

[Tyler Hicks (tyhicks)]

@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?

[Balint Reczey (rbalint)]

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