Guest session processes are not confined in 16.10 and newer releases

Bug #1663157 reported by Tyler Hicks
352
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Light Display Manager
New
Undecided
Unassigned
lightdm (Ubuntu)
Fix Released
High
Balint Reczey
Yakkety
Fix Released
High
Tyler Hicks
Zesty
Fix Released
High
Tyler Hicks
Artful
Fix Released
High
Balint Reczey

Bug Description

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)
Changed in apparmor (Ubuntu):
importance: Undecided → High
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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

Revision history for this message
John Johansen (jjohansen) wrote :

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.

Revision history for this message
John Johansen (jjohansen) wrote :

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
John Johansen (jjohansen) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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

Revision history for this message
Will Cooke (willcooke) wrote :

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

Changed in lightdm (Ubuntu Zesty):
importance: Undecided → High
Changed in lightdm (Ubuntu Yakkety):
importance: Undecided → High
Changed in lightdm (Ubuntu Artful):
status: New → Triaged
Changed in lightdm (Ubuntu Zesty):
status: New → Triaged
Changed in lightdm (Ubuntu Yakkety):
status: New → Triaged
Revision history for this message
Robert Ancell (robert-ancell) wrote :

Patch to Yakkety that disables guest support by default.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Patch to Zesty that disables guest support by default.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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)

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

Revision history for this message
Martin Pitt (pitti) wrote :

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

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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

Revision history for this message
Robert Ancell (robert-ancell) wrote :

Fixed zesty debdiff

Revision history for this message
Tyler Hicks (tyhicks) wrote :

This is CVE-2017-8900.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Yakkety):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Zesty):
status: Triaged → Fix Released
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

no longer affects: apparmor (Ubuntu Artful)
no longer affects: apparmor (Ubuntu Zesty)
no longer affects: apparmor (Ubuntu Yakkety)
Changed in apparmor (Ubuntu):
status: New → Invalid
description: updated
information type: Private Security → Public Security
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

tags: added: patch
Tyler Hicks (tyhicks)
Changed in lightdm (Ubuntu Artful):
assignee: nobody → Robert Ancell (robert-ancell)
Changed in lightdm:
assignee: nobody → Robert Ancell (robert-ancell)
Changed in lightdm (Ubuntu Yakkety):
assignee: nobody → Tyler Hicks (tyhicks)
Changed in lightdm (Ubuntu Zesty):
assignee: nobody → Tyler Hicks (tyhicks)
Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Changed in lightdm (Ubuntu Artful):
assignee: Robert Ancell (robert-ancell) → Balint Reczey (rbalint)
milestone: none → ubuntu-17.05
Balint Reczey (rbalint)
Changed in lightdm (Ubuntu Artful):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Artful):
status: In Progress → Fix Released
Mathew Hodson (mhodson)
no longer affects: apparmor (Ubuntu)
Revision history for this message
Magezi Sagesse (magezi) wrote :

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?

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

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

https://askubuntu.com/q/915415

Revision history for this message
Balint Reczey (rbalint) wrote :

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

Changed in lightdm (Ubuntu):
status: Fix Released → Triaged
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

Revision history for this message
Balint Reczey (rbalint) wrote :

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

Changed in lightdm (Ubuntu):
status: Triaged → Fix Released
tags: added: id-5a57962350afc7d4aa391919
Changed in lightdm:
assignee: Robert Ancell (robert-ancell) → nobody
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.