Bug 496247

Summary: NetworkManager-0.7 onwards lets you create ad-hoc network with no security
Product: Red Hat Enterprise Linux 5 Reporter: Saurabh Bathe <sbathe>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: desktop-bugs <desktop-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.3CC: caillon, cmeadors, cward, huzaifas, k.georgiou, msanders, peterm, rryder, tao
Target Milestone: rcKeywords: FutureFeature, OtherQA, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
NetworkManager allowed users to create completely insecure ad-hoc wireless networks and indeed, the default security setting for wifi sharing was "none". Because of this default setting and because NetworkManager did not warn users of the potential security risks, users could unwittingly compromise the security of their computers. Now, NetworkManager uses "WEP Passphrase" as the default security option for creating a new wifi network, and allows administrators to disable users' ability to share wifi connections without security in place, or their ability to share wifi connections at all. These measures make it less likely that a user could inadvertently compromise a sensitive system.
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 11:53:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 518583    
Attachments:
Description Flags
Patch allowing administrators to disable wifi sharing
none
Updated patch that ensures existing shared wifi networks are subject ot permissions checks when auto-activating a connection
none
patch to include NetworkManager.h none

Description Saurabh Bathe 2009-04-17 14:23:52 UTC
Description of problem:
NetworkManager shipped with RHEL-5.3 allows you to create completely insecure ad-hoc networks. The wireless device on a normal laptop is strong enough to be a AP within a house (or a few houses in urban housing). A non-technical user can create a network without realising what he is doing, there is no warning about the potential secuirty issues, neither can we disable this feature.

Version-Release number of selected component (if applicable):
NetworkManager > 0.7

How reproducible:
Always

Steps to Reproduce:
1. In nm-applet, click "Create New Wireless Network"
2. Type in a name, the default setting for "Wireless Security" "None"
3. Click Create
  
Actual results:
Get a nice open free network for anyone to use :)

Expected results:
1. The default should not be "None". It should atleast be WEP along with a BIG warning when the user creates a ad-hoc network without any security.
2.If possible a configurable option where creation of ad-hoc networks without proper security option can be turned of by the super user (maybe something in PolicyKit? Just a guess, I do not know much about if this could be done)
3. Or untill we can enforce any of the above, disable the feature all together?

Additional info:

Comment 1 Huzaifa S. Sidhpurwala 2009-04-17 14:28:03 UTC
So a nice thing would be

1. change default security option to something encrypted
2. provide an administrator option to disallow wifi sharing and possibly alert the user more strongly

Comment 5 Dan Williams 2009-04-22 10:42:04 UTC
Created attachment 340712 [details]
Patch allowing administrators to disable wifi sharing

This patch recognizes the following two options in /etc/sysconfig/network:

NM_WIFI_OPEN_SHARING_ALLOWED=no
 - disables creating *open* shared wifi networks

NM_WIFI_SHARING_ALLOWED=no
 - disables wifi sharing altogether

I realize now I also need an additional patch to ensure that these permissions are applied to autoconnect networks in NetworkManagerPolicy.c, but those networks wouldn't be successfully activated due to the permissions checks in nm-manager.c so it's not a huge problem.  In the mean time, please test this patch.

Comment 6 Huzaifa S. Sidhpurwala 2009-04-22 11:18:32 UTC
Seems to be a bit flaky, 
worked for the first time, but does not work once its removed and again added to /etc/sysconfig/network

Will post more concrete test results in a day.

Comment 7 Dan Williams 2009-04-22 12:17:07 UTC
Created attachment 340726 [details]
Updated patch that ensures existing shared wifi networks are subject ot permissions checks when auto-activating a connection

Comment 8 Dan Williams 2009-04-22 12:21:53 UTC
Expected behavior:

The applet will immediately update its UI when the values in /etc/sysconfig/network change.

If NM_WIFI_SHARING_ALLOWED=no the "Create new wifi network" will be grayed out, and no shared wifi connections should be visible in the "Connect to hidden..." dialog's "Connection" combo box.

If NM_WIFI_OPEN_SHARING_ALLOWED=no the "Create new wifi network" dialog will not have the "None" option in the "Security" combo box, and no open wifi network will show up in either the "Create..." or "Hidden.." dialog's "Connection" combo box.

In addition, "WEP Passphrase" should *always* be the default option in the "Create new wifi network..." dialog.

For NetworkManager itself, permissions changes will not apply to currently active connections, i.e. if you currently have an active shared wifi connection, setting NM_WIFI_SHARING_ALLOWED=no will not immediately terminate the connection, but that connection should no longer activate successfully.  Additionally, existing shared wifi connections in GConf should not be automatically chosen (if they are marked autoconnect=true) when you use the second patch (#340726).

Comment 9 Huzaifa S. Sidhpurwala 2009-04-23 09:13:30 UTC
Note the second patch is fuzzy.
you some how seemed to have missed
#include <NetworkManager.h>

I have included a patch,
so if you use 2nd and my patch the rpm builds and works :)

Comment 10 Huzaifa S. Sidhpurwala 2009-04-23 09:14:49 UTC
Created attachment 340906 [details]
patch to include NetworkManager.h

Comment 11 Dan Williams 2009-04-28 13:40:05 UTC
So the functionality and operation works for you then?

Comment 12 Dan Williams 2009-05-04 15:31:13 UTC
Please confirm that this patch provides the functionality you request so we can proceed with it in RHEL 5.4.

Comment 16 Matthew Barnes 2009-05-19 17:55:12 UTC
Patches applied to NetworkManager-0.7.0-6.el5

Comment 18 Huzaifa S. Sidhpurwala 2009-05-21 04:18:36 UTC
(In reply to comment #12)
> Please confirm that this patch provides the functionality you request so we can
> proceed with it in RHEL 5.4.  

yes it works.

Comment 19 Ruediger Landmann 2009-05-25 02:00:36 UTC
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
NetworkManager allowed users to create completely insecure ad-hoc wireless networks and indeed, the default security setting for wifi sharing was "none". Because of this default setting and because NetworkManager did not warn users of the potential security risks, users could unwittingly compromise the security of their computers. Now, NetworkManager uses "WEP Passphrase" as the default security option for creating a new wifi network, and allows administrators to disable users' ability to share wifi connections without security in place, or their ability to share wifi connections at all. These measures make it less likely that a user could inadvertently compromise a sensitive system.

Comment 21 Chris Ward 2009-07-03 18:41:49 UTC
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Comment 22 Chris Ward 2009-07-10 19:12:29 UTC
~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~

RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching.

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.

Comment 23 Chris Ward 2009-08-03 15:46:40 UTC
~~ Attention Partners - RHEL 5.4 Snapshot 5 Released! ~~

RHEL 5.4 Snapshot 5 is the FINAL snapshot to be release before RC. It has been 
released on partners.redhat.com. If you have already reported your test results, 
you can safely ignore this request. Otherwise, please notice that there should be 
a fix available now that addresses this particular issue. Please test and report 
back your results here, at your earliest convenience.

If you encounter any issues while testing Beta, please describe the 
issues you have encountered and set the bug into NEED_INFO. If you 
encounter new issues, please clone this bug to open a new issue and 
request it be reviewed for inclusion in RHEL 5.4 or a later update, if it 
is not of urgent severity. If it is urgent, escalate the issue to your partner manager as soon as possible. There is /very/ little time left to get additional code into 5.4 before GA.

Partners, after you have verified, do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other 
appropriate customer representative.

Comment 25 Chris Ward 2009-08-25 13:26:03 UTC
Please update us with the latest test results for confirming the
resolution of this request. Thank you.

Comment 26 Huzaifa S. Sidhpurwala 2009-08-26 10:22:20 UTC
works me me!

Comment 27 errata-xmlrpc 2009-09-02 11:53:53 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1389.html