Guest session processes are not confined in 16.10 and newer releases
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Light Display Manager |
Undecided
|
Unassigned | ||
| lightdm (Ubuntu) |
High
|
Balint Reczey | ||
| Yakkety |
High
|
Tyler Hicks | ||
| Zesty |
High
|
Tyler Hicks | ||
| Artful |
High
|
Balint Reczey |
Bug Description
Processes launched under a lightdm guest session are not confined by the /usr/lib/
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/
Expected output, as seen in Ubuntu 16.04 LTS, is:
/usr/lib/
Running the command inside of an Ubuntu 16.10 and newer guest session results in:
unconfined
CVE References
Changed in apparmor (Ubuntu): | |
importance: | Undecided → High |
Tyler Hicks (tyhicks) wrote : | #1 |
Tyler Hicks (tyhicks) wrote : | #2 |
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) wrote : | #3 |
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) wrote : | #4 |
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:/
Robert Ancell (robert-ancell) wrote : | #5 |
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) wrote : | #6 |
@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) wrote : | #7 |
The proper way to do this would be to use pam_apparmor, similar to how selinux is doing this, through systemd --user
/etc/
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) wrote : | #8 |
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) wrote : | #9 |
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/
I also did a bit of experimenting with adding "AppArmorProfil
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) wrote : | #10 |
@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) wrote : | #11 |
We need to either find a solution to this issue, or push an update to disable guest sessions.
Will Cooke (willcooke) wrote : | #12 |
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 |
Robert Ancell (robert-ancell) wrote : | #13 |
Patch to Yakkety that disables guest support by default.
Robert Ancell (robert-ancell) wrote : | #14 |
Patch to Zesty that disables guest support by default.
Robert Ancell (robert-ancell) wrote : | #15 |
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/
/etc/lightdm/
/usr/share/
Tyler Hicks (tyhicks) wrote : | #16 |
@robert-ancell thanks for the debdiffs! Is the addition of debian/
Martin Pitt (pitti) wrote : | #17 |
> I also did a bit of experimenting with adding "AppArmorProfil
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/
[Service]
AppArmorProfile
so that it applies *only* to the guest UID.
3) lightdm calls org.freedesktop
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(149444866
audit: type=1400 audit(149444866
audit: type=1400 audit(149444866
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/
Robert Ancell (robert-ancell) wrote : | #18 |
@Tyler - yes, the 99 should have been removed...
Robert Ancell (robert-ancell) wrote : | #19 |
Fixed zesty debdiff
Tyler Hicks (tyhicks) wrote : | #20 |
This is CVE-2017-8900.
Launchpad Janitor (janitor) wrote : | #21 |
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/
- debian/
- Disable guest sessions by default, this can be overridden by custom
- 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 |
Launchpad Janitor (janitor) wrote : | #22 |
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/
- debian/
- Disable guest sessions by default, this can be overridden by custom
- 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 |
Tyler Hicks (tyhicks) wrote : | #23 |
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/
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 |
Tyler Hicks (tyhicks) wrote : | #24 |
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/
# Manually enable guest sessions despite them not being confined
# IMPORTANT: Makes the system vulnerable to CVE-2017-8900
# https:/
[Seat:*]
allow-guest=true
tags: | added: patch |
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) |
Steve Langasek (vorlon) wrote : | #25 |
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 |
Changed in lightdm (Ubuntu Artful): | |
status: | Triaged → In Progress |
Launchpad Janitor (janitor) wrote : | #26 |
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/
- debian/
- Disable guest sessions by default, this can be overridden by custom
- 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 |
no longer affects: | apparmor (Ubuntu) |
Magezi Sagesse (magezi) wrote : | #27 |
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) wrote : | #28 |
@Magezi: Please note that this is a bug report, not a support forum. This Ask Ubuntu question may help:
Balint Reczey (rbalint) wrote : | #29 |
Reopening, since the guest session is disabled by default but it is still not confined.
Changed in lightdm (Ubuntu): | |
status: | Fix Released → Triaged |
Tyler Hicks (tyhicks) wrote : | #30 |
@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) wrote : | #31 |
@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 |
After coming back to this bug, I noticed that Robert was not subscribed and couldn't see the bug. He's now subscribed.