Bug 585182 - non-local user can disable the network
non-local user can disable the network
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: NetworkManager (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Dan Williams
desktop-bugs@redhat.com
: OtherQA
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-23 07:29 EDT by Pierre Ossman
Modified: 2010-11-15 08:50 EST (History)
6 users (show)

See Also:
Fixed In Version: NetworkManager-0.8.1-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-15 08:50:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 619323 None None None Never

  None (edit)
Description Pierre Ossman 2010-04-23 07:29:26 EDT
Description of problem:
Using the ThinLinc terminal server, I started a new desktop and could uncheck "Enable networking" in nm-applet. This is of course catastrophic to allow for a non-local, non-root user.

Version-Release number of selected component (if applicable):
polkit-0.96-1.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Log in with a non-root user using ThinLinc
2. Right click on nm-applet
3. Select "Enable networking"
  
Actual results:
The network is disabled.


Expected results:
An error telling me I don't have authorisation.


Additional info:

ConsoleKit has no strange ideas about this user being privileged to do this:

[tltest@rhel6beta ~]$ ck-list-sessions 
Session9:
	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:24:49.875374Z'
	login-session-id = '4294967295'
Comment 2 RHEL Product and Program Management 2010-04-23 08:43:41 EDT
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.
Comment 3 David Zeuthen 2010-04-23 19:22:59 EDT
(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?
Comment 4 Pierre Ossman 2010-04-26 04:50:18 EDT
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.
Comment 5 David Zeuthen 2010-04-26 09:07:07 EDT
(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.
Comment 6 David Zeuthen 2010-04-26 09:14:07 EDT
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.
Comment 7 Pierre Ossman 2010-04-26 09:50:01 EDT
(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.
Comment 8 Pierre Ossman 2010-04-26 09:57:50 EDT
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 9 David Zeuthen 2010-04-26 13:29:30 EDT
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.
Comment 10 Pierre Ossman 2010-05-03 05:25:27 EDT
Dan? Comments?
Comment 11 Dan Williams 2010-05-26 05:56:35 EDT
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.
Comment 13 Dan Williams 2010-06-22 15:44:23 EDT
This was fixed upstream as of:

commit 6d719a0a385e61651cbe8500c3dd3c0e14eedb37
Author: Dan Williams <dcbw@redhat.com>
Date:   Fri Jun 4 13:55:45 2010 -0700
Comment 20 Vladimir Benes 2010-08-18 07:03:44 EDT
Pierre,
could you please verify the fix for this issue in NM-0.8.1-2.el6 or newer?

thanks,
Vladimir
Comment 21 Pierre Ossman 2010-08-18 09:41:07 EDT
Downloaded beta 2 yesterday, so I'm hoping to do some testing this week. Stay tuned...
Comment 22 Pierre Ossman 2010-08-19 07:41:18 EDT
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.
Comment 23 Pierre Ossman 2010-08-19 07:42:20 EDT
Version of NM:

$ rpm -q NetworkManager
NetworkManager-0.8.1-2.el6.x86_64
Comment 24 Vladimir Benes 2010-08-19 07:50:43 EDT
reproducible using NetworkManager-0.8.1-5.el6.x86_64
Comment 25 Dan Williams 2010-08-19 10:53:44 EDT
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!
Comment 26 Pierre Ossman 2010-08-20 04:22:04 EDT
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.
Comment 27 Dan Williams 2010-08-20 15:31:54 EDT
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.
Comment 28 Dan Williams 2010-08-20 15:32:24 EDT
In any case, we should either file a new bug for the wifi stuff, or clone this one and rename it to wifi.
Comment 30 Pierre Ossman 2010-08-23 04:44:42 EDT
(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.
Comment 31 Christopher Aillon 2010-08-23 15:21:09 EDT
Moving back to ON_QA, then.  Thanks!
Comment 32 releng-rhel@redhat.com 2010-11-15 08:50:46 EST
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.

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