Bug 585952

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