Hide Forgot
Cause: Bug which caused that remote-sessions (vnc sessions) were marked as local. Consequence: A valid, authenticated system user could use this flaw to escalate their privileges (become member of more privileged policy group) by initiating a remote VNC session. Fix: Added additional logic to the code which causes that newly created session is marked as local only if it originates from existing local session. Result: vnc sessions are no longer marked as local to the system.
Description of problem: ConsoleKit misrepresents a session as being local when it isn't. Might have security implications. Version-Release number of selected component (if applicable): ConsoleKit-0.4.1-3.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. ssh to machine (i.e. non-local) 2. run vncserver 3. connect to the started VNC server Actual results: Session inside vnc is considered local Expected results: Session inside vnc is NOT considered local Additional info: [tltest@rhel6beta Desktop]$ ck-list-sessions Session17: unix-user = '42' realname = '(null)' seat = 'Seat1' session-type = 'LoginWindow' active = TRUE x11-display = ':1' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2010-04-26T14:01:34.386600Z' login-session-id = '4294967295' idle-since-hint = '2010-04-26T14:06:34.697758Z' Session22: unix-user = '500' realname = '(null)' seat = 'Seat4' session-type = '' active = FALSE x11-display = ':2' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2010-04-26T14:14:50.193960Z' login-session-id = '1509' (Session22 is the VNC one, and Session17 is GDM) Note that avoiding ConsoleKit in the VNC startup doesn't give much as the user can easily do ck-launch-session inside VNC later anyway.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
So the reason for this is that the session is actually running locally. The X server process and the session leader are both local to the system. Running vncserver is more or less functionally equivalent to logging in from GDM, using vino (or similar) to export your user session over the network. That session would have is-local=true as well even though it is available remotely. One detail here is that the seat-id is not Seat1. This can be used to assign authorization policies (afaik policykit supports this) in addition to the is-local property. For auditing purposes you can track the user login that started the vncserver using the login-session-id. Theoretically, if we deem it necessary, we can trace the vncserver session back to the ssh login using the login-session-id and mark any session that derives from a remote login to also be remote.
Other options in addition to trying to reverse map the login-session-id include: * Adding an additional check for the XFree86_VT property on the root window * Allowing only privileged callers to start sessions with is-local=true I'm leaning toward the second at the moment.
(In reply to comment #3) > So the reason for this is that the session is actually running locally. The X > server process and the session leader are both local to the system. > So what's non-local in that meaning? XDMCP with the X server running elsewhere? And what's the value in that definition? From what I've seen, people interpret "local" as meaning "has physical access to the machine" and become more lenient with security. That definition makes more sense as it focuses on where the user is located rather then the technical detail of whether it is VNC or X11 packets that are going over the network. > Running vncserver is more or less functionally equivalent to logging in from > GDM, using vino (or similar) to export your user session over the network. > That session would have is-local=true as well even though it is available > remotely. Not really. That scenario requires you to first log in locally. (Although it would be nice if the system could detect that the user is now no longer at the machine, but accessing it remotely) A more fair comparison would be to log in over ssh with X11 forwarding to a remote X server. > > One detail here is that the seat-id is not Seat1. This can be used to assign > authorization policies (afaik policykit supports this) in addition to the > is-local property. > How do you tell the difference from a multi-seat machine and one with remote access in that case? > For auditing purposes you can track the user login that started the vncserver > using the login-session-id. > > Theoretically, if we deem it necessary, we can trace the vncserver session back > to the ssh login using the login-session-id and mark any session that derives > from a remote login to also be remote. Since is-local has security implications, the default should really be to have it false and only set it to true when we're really, _really_ sure that the user is locally at the machine (i.e. can be traced to a local tty).
(In reply to comment #4) > Other options in addition to trying to reverse map the login-session-id > include: > > * Adding an additional check for the XFree86_VT property on the root window What will prevent someone from adding that to a remotely started X server? > * Allowing only privileged callers to start sessions with is-local=true > > I'm leaning toward the second at the moment. Sounds safer, but how does that clash with the plan to have Xorg be root-less?
Any progress here? I'm not allowed to read the upstream bug entry, so I can't see if there is anything happening there.
Now that the upstream bug is resolved, could we get an updated package for rhel6 to test with?
Ping! Comment? 6.1?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
This is public via the upstream bug. I'm opening this up. I've assigned this bug CVE-2010-4664
Backporting upstream commit 4f88228f31a63c026c424a92827f26ad7535275c should fix this.
1) Reproducer # yum -y groupinstall "X Window System" # yum -y install tigervnc-server xterm # echo 'VNCSERVERS="0:root"' >> /etc/sysconfig/vncservers # vncpasswd ## <enter password> # vncserver :0 ## Connect to vncserver via another machine (vncviewer) ## and run ck-launch-session # ck-list-sessions 2) Output a) Old package (ConsoleKit-0.4.1-3.el6.x86_64) # ck-list-sessions Session3: unix-user = '0' realname = 'root' seat = 'Seat4' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '/dev/pts/1' remote-host-name = '' is-local = TRUE on-since = '2016-03-02T09:02:38.362275Z' login-session-id = '27' b) New package (ConsoleKit-0.4.1-5.el6.x86_64) # ck-list-sessions Session2: unix-user = '0' realname = 'root' seat = 'Seat3' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '/dev/pts/1' remote-host-name = '' is-local = FALSE on-since = '2016-03-02T09:14:03.494951Z' login-session-id = '1'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0942.html