Bug 1269917 - lxdm: X server authorizations are not revoked after user log out
Summary: lxdm: X server authorizations are not revoked after user log out
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: lxdm
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christoph Wickert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-08 13:32 UTC by Tomas Hoger
Modified: 2016-07-19 18:09 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-07-19 18:09:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Tomas Hoger 2015-10-08 13:32:52 UTC
Quoting from the report I sent upstream:

lxdm does not restart X server after user log out.  It also does not
seem to do anything to revoke granted authorizations.  So the
following attack is possible on multi-user systems:

- User1 logs in via lxdm.  During the session start up, authentication
  cookie is copied to user1's .Xauthority.
- User1 logs out.
- As X server is not restarted and X server authentication cookies are
  not regenerated, user1 can still connect via text console or remotely
  via SSH and start X applications on the X server.
- No authentication cookie change happens after log in of some other
  user2, so user1 can also mess with user2's session.

Besides MIT-MAGIC authentication cookies, there are other
authorizations that may need to be cleaned up.  For example, user1 can
run 'xhost +si:localuser:`id -un`' while they are logged in.  That
makes X server accept connections from given local user regardless of
whether they have valid cookie or not.  This authorization is also not
revoked after user log out.

At least in Fedora, 'xhost +si:localuser:`id -un`' is run when
initializing user's X session.

Version-Release number of selected component (if applicable):

Tested with 0.4.1 in F22, but also with the 0.5.1-7.D20151007gite8f38708 from master rebuilt for F22.

Comment 1 Tomas Hoger 2015-10-09 08:03:14 UTC
Upstream pointed out that it's already possible to have lxdm restart X server after user logout by setting reset = 1 in the [server] section of the lxdm.conf.  This functionality is available in Fedora 0.4.1 packages.

Upstream also explained they default to no X restart to have faster and smoother logout.  The issue is also pretty minor on single user machines.  However, I'm not convinced Fedora should only assume it's only used in such use cases and default to safer reset=1.  I see other *DMs (gdm, kdm, lightdm) do X restarts as well.

Comment 2 Tomas Hoger 2015-11-20 09:51:28 UTC
Making this public.

Comment 3 Fedora Update System 2015-11-24 14:07:50 UTC
lxdm-0.5.3-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-e3ec4cbf8f

Comment 4 Fedora Update System 2015-11-25 02:53:20 UTC
lxdm-0.5.3-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update lxdm'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-e3ec4cbf8f

Comment 5 Fedora Update System 2015-12-06 01:23:51 UTC
lxdm-0.5.3-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Fedora End Of Life 2016-07-19 18:09:23 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.