guest-session has read access to other users home directories

apparmor_status in my main session with the guest session open:

albert@compal:~$ sudo apparmor_status
[sudo] password for albert:
apparmor module is loaded.
10 profiles are loaded.
10 profiles are in enforce mode.
   /usr/lib/connman/scripts/dhclient-script
   /usr/share/gdm/guest-session/Xsession
   /usr/bin/evince-previewer
   /usr/sbin/tcpdump
   /usr/lib/cups/backend/cups-pdf
   /usr/bin/evince-thumbnailer
   /sbin/dhclient3
   /usr/bin/evince
   /usr/sbin/cupsd
   /usr/lib/NetworkManager/nm-dhcp-client.action
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode :
   /usr/sbin/cupsd (1633)
   /sbin/dhclient3 (1404)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

If I do the same in Jaunty, I see 34 "/usr/share/gdm/guest-session/Xsession processes" in enforced mode.

Indeed it now seems that there is no restriction at all any more. The profile does not even mention /home, and yet I can browse there, also in /selinux (which is also not mentioned in /etc/apparmor.d/gdm-guest-session). The profile didn't change in ages, so I suspect it's either a regression or a behaviour change in apparmor. Need to investigate further.

Right, seems it's not running under the apparmor wrapper at all. Something broke the wrapping recently. Confirmed on my box.

gdm needs to call /usr/share/gdm/guest-session/Xsession for the apparmor profile to be applied, but 14_guest_session.patch in gdm doesn't seem to set this.

Marc Deslauriers [2009-10-14 16:41 -0000]:
> gdm needs to call /usr/share/gdm/guest-session/Xsession for the apparmor
> profile to be applied, but 14_guest_session.patch in gdm doesn't seem to
> set this.

It's not meant to. It should just hardcode the "guest-restricted"
session type, which runs
/usr/share/xsessions/guest-restricted.desktop, which in turn runs
/usr/share/gdm/guest-session/Xsession .

That definitively worked a few weeks ago, but not now any more. Don't
worry, I suspect it's something trivial, and I'll get to it. I just
have some more tricky bugs to solve before, so I'll postpone this for
a day or two.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

gdm now uses a cache directory at /usr/share/gdm for dmrc files. Upon login, it reads files from the cache only. Once you've logged in, it will then sync the .dmrc file in your home directory to the cache location _if_ the .dmrc file in your home directory is owned by you.

Since the guest-session-setup.sh script would create the .dmrc file in the guest user directory, and not in the cache directory, it was not being read by gdm. gdm was using the default session, which was not protected by apparmor.

This problem is fixed by modifying guest-session-setup.sh to create the dmrc file in the gdm cache directory with root ownership. guest-session-cleanup.sh now removes the dmrc file from the cache directory to make sure the guest user can't poison it.

Committed to bzr, thanks Marc for figuring this out!

This bug was fixed in the package gdm-guest-session - 0.14

---------------
gdm-guest-session (0.14) karmic; urgency=low

  [ Marc Deslauriers ]
  * gdm/guest-session-setup.sh: create the dmrc file in the gdm cache
    location so the proper session gets started (LP: #449712)
  * gdm/guest-session-cleanup.sh: remove guest user directory from gdm
    cache directory to prevent user modifications from staying

  [ Martin Pitt ]
  * debian/control: Update Vcs-Bzr: for changed branch owner (now
    ~ubuntu-desktop).
  * Bumped Standards-Version to 3.8.3 (no changes necessary).
  * gdm/guest-session-setup.sh: Don't fail if /var/cache/gdm/guest already
    exists. (Regression from Marc's fix above)

 -- Martin Pitt <email address hidden> Thu, 15 Oct 2009 12:14:57 +0200