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.

(In reply to comment #0)
> Description of problem:
> Using the ThinLinc terminal server

Sounds like a problem with ThinLinc and/or how it is integrated with the operating system. Why are you filing this against polkit?

I'm guessing that polkit is what makes the decision to allow/deny the operation here. If that's wrong then feel free to move it.

As for not seeing this as a ThinLinc bug, it's simply because of the fact that the system should default to deny, not allow when a non-polkit (or non-consolkit, etc) system is involved. If there is any doubt that the user isn't local, then he/she should not be allowed to tamper with the network settings. You can treat the bug as "legacy applications are incorrectly given full access" if you'd like.

I don't know how to debug the interaction here so I don't know what makes the system think that this operation should be allowed.

(In reply to comment #4)
> I'm guessing that polkit is what makes the decision to allow/deny the operation
> here. If that's wrong then feel free to move it.

Yes polkit is indeed the entity making the authorization decision (on behalf of NetworkManager) but polkit does so assuming that the data in ConsoleKit is actually valid. And comment 0 clearly shows that the session is indeed reported as active and local by ConsoleKit so it's all good - polkit is working as expected.

> As for not seeing this as a ThinLinc bug, it's simply because of the fact that
> the system should default to deny, not allow when a non-polkit (or
> non-consolkit, etc) system is involved. If there is any doubt that the user
> isn't local, then he/she should not be allowed to tamper with the network
> settings. You can treat the bug as "legacy applications are incorrectly given
> full access" if you'd like.
> 
> I don't know how to debug the interaction here so I don't know what makes the
> system think that this operation should be allowed.    

I can't make that call as I haven't reviewed the ThinLinc source code and it doesn't appear to be in the distribution you are filing a bug against. From what I can tell the ThinLinc source code is not publicly available.

My guess is that ThinLinc simply makes a couple of assumptions that it shouldn't be making and this causes ConsoleKit to report the session as active. My guess is still that it's just ThinLinc making assumptions that it shouldn't be making and perhaps hooking into interfaces that it shouldn't. I don't know.

I'm reassigning this bug to ConsoleKit for now.

Actually, reassigning back (for now) as the output in comment 0 indicates this is just the local gdm window.

Pierre, please try this from a gnome-terminal instance running inside the ThinLinc session

 1. output of 'id' and 'ck-list-sessions'
 2. output of 'pkaction --verbose --action-id org.freedesktop.udisks.filesystem-mount'
 3. output of 'pkcheck --action-id org.freedesktop.udisks.filesystem-mount --process $$'
 4. output of 'pkaction --verbose --action-id org.freedesktop.network-manager-settings.system.modify'
 5. output of 'pkcheck --action-id org.freedesktop.network-manager-settings.system.modify --process $$'

Thanks.

(In reply to comment #6)
> Actually, reassigning back (for now) as the output in comment 0 indicates this
> is just the local gdm window.
> 

Right. I probably should have pointed that out more clearly.

> Pierre, please try this from a gnome-terminal instance running inside the
> ThinLinc session
> 
>  1. output of 'id' and 'ck-list-sessions'
>  2. output of 'pkaction --verbose --action-id
> org.freedesktop.udisks.filesystem-mount'
>  3. output of 'pkcheck --action-id org.freedesktop.udisks.filesystem-mount
> --process $$'
>  4. output of 'pkaction --verbose --action-id
> org.freedesktop.network-manager-settings.system.modify'
>  5. output of 'pkcheck --action-id
> org.freedesktop.network-manager-settings.system.modify --process $$'
> 
> Thanks.    

[tltest@rhel6beta ~]$ id
uid=500(tltest) gid=500(tltest) groups=500(tltest) context=unconfined_u:system_r:initrc_t:s0
[tltest@rhel6beta ~]$ ck-list-sessions
Session13:
	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-23T11:34:39.831531Z'
	login-session-id = '4294967295'
	idle-since-hint = '2010-04-26T09:50:40.264573Z'
[tltest@rhel6beta ~]$ pkaction --verbose --action-id org.freedesktop.udisks.filesystem-mount
org.freedesktop.udisks.filesystem-mount:
  description:       Mount a device
  message:           Authentication is required to mount the device
  vendor:            The udisks Project
  vendor_url:        http://udisks.freedesktop.org/
  icon:              drive-removable-media
  implicit any:      no
  implicit inactive: no
  implicit active:   yes

[tltest@rhel6beta ~]$ pkcheck --action-id org.freedesktop.udisks.filesystem-mount --process $$
Not authorized.
[tltest@rhel6beta ~]$ pkaction --verbose --action-id org.freedesktop.network-manager-settings.system.modify
org.freedesktop.network-manager-settings.system.modify:
  description:       Modify system connections
  message:           System policy prevents modification of system settings
  vendor:            NetworkManager
  vendor_url:        http://www.gnome.org/projects/NetworkManager
  icon:              nm-icon
  implicit any:      no
  implicit inactive: no
  implicit active:   auth_admin_keep

[tltest@rhel6beta ~]$ pkcheck --action-id org.freedesktop.network-manager-settings.system.modify --process $$
Not authorized.


Just for an extra check I also did this:

[tltest@rhel6beta ~]$ ps ax  | grep nm-applet
16355 ?        S      0:00 nm-applet --sm-disable
[tltest@rhel6beta ~]$ pkcheck --action-id org.freedesktop.network-manager-settings.system.modify --process 16355
Not authorized.


And just to make sure I wasn't hallucinating, immediately after doing the above I right clicked on nm-applet and unchecked "Enable networking". And again I was left without a network.

Another discovery! We can completely take ThinLinc out of the mix here. The following also works when it shouldn't:

[user@othermachine ~]$ ssh rhel6beta
[tltest@rhel6beta ~]$ nm-applet
Right click and uncheck "Enable networking"

So it seems like there is a hole somewhere in the nm-applet/NM/polkit interaction that misses this command.

Comment 7 indicates that polkit is working as expected - e.g. your user is not authorized (because there is no entry in the ConsoleKit database).

It looks like NetworkManager simply isn't using polkit for the "Enable Networking" check button (or if it is, it is doing something wrong). Reassigning to NetworkManager for this.

Dan? Comments?

Yeah, I'm working through it.  It's not as easy as just PK protecting the method here since we need to add a method for clients to query whether they can actually alter the network enabled state or not (ie "yet", "no" or "auth" indicating the privilege level) so that the UI can do something intelligent.

Thats fairly straightforward but it takes some code.  In current NM we'll want to lock down the 'Sleep' method to be root-only since that's only twiddled by the pm-utils scripts now, and PK-protect the Enable() method.

This was fixed upstream as of:

commit 6d719a0a385e61651cbe8500c3dd3c0e14eedb37
Author: Dan Williams <dcbw>
Date:   Fri Jun 4 13:55:45 2010 -0700

Pierre,
could you please verify the fix for this issue in NM-0.8.1-2.el6 or newer?

thanks,
Vladimir

Downloaded beta 2 yesterday, so I'm hoping to do some testing this week. Stay tuned...

Partially fixed. nm-applet no longer starts at all, giving this:

** (nm-applet:5649): WARNING **: <WARN>  request_name(): Could not acquire the NetworkManagerUserSettings service.
  Error: (9) Connection ":1.58" is not allowed to own the service "org.freedesktop.NetworkManagerUserSettings" due to security policies in the configuration file

Acceptable I suppose. Although an icon with some information that you're not allowed to do anything might be more user friendly.

Trying to disable the network with nmcli gets properly refused:

$ nmcli nm sleep

** (process:5686): WARNING **: Error enabling/disabling networking: Not authorized to enable/disable networking

However, some things are still unprotected. E.g.:

$ nmcli nm wifi off

$ nmcli nm
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         connected       enabled         disabled   enabled         enabled   

$ nmcli nm wifi on

$ nmcli nm
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         connected       enabled         enabled    enabled         enabled   

So I think you need to have another go at checking that everything does proper access checks.

Version of NM:

$ rpm -q NetworkManager
NetworkManager-0.8.1-2.el6.x86_64

reproducible using NetworkManager-0.8.1-5.el6.x86_64

By default we ship a fairly permissive setup.  If you'd like to enforce authentication before users can enable/disable network, wifi, etc, look here:

/usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy

Note all the "yes" items.  If you'd like to require authentication, change one to "auth_admin" for example.  You can also override these with the PolicyKit "local authority" mechanism in /etc/polkit-1/localauthority.conf.d by dropping an override file there when deploying.

Let me know if this works for you!

I'm afraid I don't see what to change there. Looking at the wifi setting, it is identical to the global network switch:

  <action id="org.freedesktop.NetworkManager.enable-disable-network">
    <description>Enable or disable system networking</description>
    <message>System policy prevents enabling or disabling system networking</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

...

  <action id="org.freedesktop.NetworkManager.enable-disable-wifi">
    <description>Enable or disable WiFi devices</description>
    <message>System policy prevents enabling or disabling WiFi devices</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

Even so, things should be secure out of box. Even more so on a server distribution like RHEL. Being able to fiddle with network settings as an unprivileged user via a remote connection is pretty poor default IMO.

I'm not familiar with the new pk rewrite. Is it no longer possible to allow NM control from a local, active session whilst denying it to everyone else? That seems like the sensible default.

Ah right; so the issue with Enable Networking *is* in fact fixed.  The problem here is with "Enable Wireless", correct?

NM has always used properties for the Wifi/WWAN enable toggles, and unfortunately those can't be protected with PK in the same way as method calls can, becasue dbus-glib hides the necessary information.  There may be some workarounds that we can use (and we've discussed them before) so I'll look into the wifi/wwan switches more.

But WRT to actual servers, they most likely wont' be running wifi devices which makes this somewhat less severe.

In any case, we should either file a new bug for the wifi stuff, or clone this one and rename it to wifi.

(In reply to comment #28)
> In any case, we should either file a new bug for the wifi stuff, or clone this
> one and rename it to wifi.

I've opened bug 626337. I guess this one can be closed now though.

Moving back to ON_QA, then.  Thanks!

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.