Same problem for me in Fedora 18 and now Fedora 19.

Is there a workaround for this problem? Because right now a normal user can act like root and mess up the whole network interface.

Is

/etc/dbus-1/system.d/nm-ifcfg-rh.conf

somehow related to this problem? Is this the file which grants the NetworkManager the rights to modify /etc/sysconfig/network-scripts/ifcfg-eth0 as normal user?

I found the policy which controls the NetworkManager, it is

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

I changed the settings for

org.freedesktop.NetworkManager.settings.modify.system

from 

    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>

to

    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>

"auth_admin_keep" is the solution. This way you need the system password to change settings, it looks like USERCTL=no in /etc/sysconfig/network-scripts/ifcfg-eth0 is completely useless now.

At the moment USERCTL is not read by NM.

If it becomes a priority to support USERCTL, then the solution would be to map USERCTL to a permissions key of "user:root" such that only root can modify the configuration and control the connection.  This would be in addition to and in parallel to the PolicyKit permissions structure, and would prevent non-root users from even seeing the conneciton in the first place.

There should be a simple flag for the administrator to allow console users modifying the network configuration (on, off, lan, wlan, vpn, 802.1x, etc.) or disallow it. This flag can be a variable in the ifcfg-* file, a command to call (like getsebool / setsebool) or something similar. I think this depends on the security mechanism that implements the restriction. The variable USERCTL would be ok for me.

The use case for the first (allow) are personal mobile devices like notebooks and some pcs at home. The other (disallow) are business desktop pcs, workstations, servers, etc., which are central managed and connected to a managed network where users must not change the network configuration.


A note why I found the problem:

On previous Fedora releases (Fedora 16 and earlier) we have used NetworkManager only on notebook, where it is ok for me that users can change the network configuration to get network connection in their hotel, conference, etc.

On our desktop pcs we had disabled NetworkManager and have used network scripts to start the network at boot time. We did this until Fedora 16. We didn't really use Fedora 17 and 18, and now with Fedora 19 I leave NetworkManager enabled und use it on the desktops and servers to, because so many other services depends on a running NetworkManager service (otherwise I got many errors, for example in ~/.xsession-errors and /var/log/messages), so I have decided to use NetworkManager (instead to "fight" against it) and not "network".

With Fedora 19 NetworkManager has become more features so it can be used on desktops and servers and not only mobile hosts, and I saw that bonding and bridging is prepeared for Fedora 20.

As NetworkManager is running on Fedora 19, the nm-applet appears automatically on users desktop to see and manage network connections. In previous releases (Fedora 16) I allowed NetworkManager only on notebooks. On desktops no nm-appled appeared because NetworkManager was not running.

I use as workaround now a rule in 

/etc/polkit-1/rules.d

for example:

----------------
polkit.addRule(function(action, subject) {
	if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0) {
		// Only admin can change it.
		return polkit.Result.AUTH_ADMIN;
	}

	return polkit.Result.NOT_HANDLED;
});
----------------

This way it is not necessary to modify 

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

Of course I would prefer USERCTL in the /etc/sysconfig/network-scripts/ifcfg-* files...

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

(In reply to JM from comment #6)
> I use as workaround now a rule in 
> 
> /etc/polkit-1/rules.d
> 
> for example:
> 
> ----------------
> polkit.addRule(function(action, subject) {
> 	if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0) {
> 		// Only admin can change it.
> 		return polkit.Result.AUTH_ADMIN;
> 	}
> 
> 	return polkit.Result.NOT_HANDLED;
> });
> ----------------
> 
> This way it is not necessary to modify 
> 
> /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy
> 
> Of course I would prefer USERCTL in the
> /etc/sysconfig/network-scripts/ifcfg-* files...

Note that you can also protect ifcfg files with:

USERS=root foobar baz blah

key, and the connection will only be usable (and editable) by those specific users.  Unfortunately, USERCTL=yes/no is simply not flexible enough anymore, in a world where some users may need to change network settings, and other users may not.  This is why we have PolicyKit and connection permissions.

The best option here is to use PolicyKit to restrict which operations a user can perform on a per-user or per-group basis, as you've found you can do with the scripts.  NetworkManager provides a number of POlicyKit permissions, which you've seen in the .policy file.  Note that root is *always* allowed to perform all operations no matter what.  So you could certainly just lock everything down by overriding the .policy file with your own.