Ubuntu
network-manager package

NM ignores "system"-level connections if files are world-readable

Bug #321442 reported by Steve Langasek
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: network-manager

Trying to create a system-level connection for my wep-authenticated wireless has never worked correctly. The connection only comes up after login, not before as I would expect.

In my latest test with jaunty, I've created my system profile by:

  right click nm-applet -> Edit Connections -> Wireless -> Auto home-net -> Edit -> Available to all users -> Apply

This immediately causes the connection to disappear from the list of known Wireless profiles and causes /etc/NetworkManager/system-connections/Auto home-net to be created. The connection stays active, until I kill nm-applet. After that, the connection won't come up again until nm-applet is started, even if I cycle NetworkManager and nm-system-settings both.

NM syslog entries after a restart, without nm-applet:

Jan 26 04:23:33 dario NetworkManager: <info> starting...
Jan 26 04:23:33 dario NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/pci_8086_4227_rfkill_3945ABG_wlan
Jan 26 04:23:33 dario NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/iwl_wlan_switch
Jan 26 04:23:33 dario NetworkManager: <info> eth0: driver is 'e1000e'.
Jan 26 04:23:33 dario NetworkManager: <info> Found new Ethernet device 'eth0'.
Jan 26 04:23:33 dario NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_15_58_81_5a_8c
Jan 26 04:23:33 dario NetworkManager: <info> wlan0: driver is 'iwl3945'.
Jan 26 04:23:33 dario NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01).
Jan 26 04:23:33 dario NetworkManager: <info> Found new 802.11 WiFi device 'wlan0'.
Jan 26 04:23:33 dario NetworkManager: <info> (wlan0): exported as /org/freedesktop/Hal/devices/net_00_19_d2_76_2a_cb
Jan 26 04:23:33 dario NetworkManager: <info> Trying to start the system settings daemon...
Jan 26 04:23:33 dario NetworkManager: <WARN> killswitch_getpower_reply(): Error getting killswitch power: Method "GetPower" with signature "" on interface "org.freedesktop.Hal.Device.KillSwitch" doesn't exist .
Jan 26 04:23:33 dario nm-system-settings: Loaded plugin ifupdown: (C) 2008 Canonical Ltd. To report bugs please use the NetworkManager mailing list.
Jan 26 04:23:33 dario nm-system-settings: Loaded plugin keyfile: (c) 2007 - 2008 Red Hat, Inc. To report bugs please use the NetworkManager mailing list.
Jan 26 04:23:33 dario NetworkManager: <info> (eth0): now unmanaged
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): device state change: 1 -> 2
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): bringing up device.
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): preparing device.
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): deactivating device (reason: 2).
Jan 26 04:23:37 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:23:37 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:23:37 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): device state change: 2 -> 3
Jan 26 04:23:37 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): supplicant interface state: starting -> ready

The "Unmanaged Device" above should be eth0, not relevant here.

After waiting around a minute for NM to do something on its own, I then launch nm-applet and the connection immediately starts:

Jan 26 04:24:31 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) starting connection 'Auto home-net'
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): device state change: 3 -> 4
Jan 26 04:24:38 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): device state change: 4 -> 5
Jan 26 04:24:38 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0/wireless): access point 'Auto home-net' has security, but secrets are required.
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): device state change: 5 -> 6
Jan 26 04:24:38 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): device state change: 6 -> 4
Jan 26 04:24:38 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): device state change: 4 -> 5
Jan 26 04:24:38 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0/wireless): connection 'Auto home-net' has security, and secrets exist. No new secrets needed.
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'ssid' value 'home-net'
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'scan_ssid' value '1'
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'key_mgmt' value 'NONE'
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'auth_alg' value 'OPEN'
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'wep_key0' value '<omitted>'
Jan 26 04:24:38 dario NetworkManager: <info> Config: added 'wep_tx_keyidx' value '0'
Jan 26 04:24:38 dario NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jan 26 04:24:38 dario NetworkManager: <info> Config: set interface ap_scan to 1
Jan 26 04:24:38 dario NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected
Jan 26 04:24:39 dario NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jan 26 04:24:41 dario NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
Jan 26 04:24:41 dario NetworkManager: <info> (wlan0): supplicant connection state: associating -> associated
Jan 26 04:24:41 dario NetworkManager: <info> (wlan0): supplicant connection state: associated -> completed
Jan 26 04:24:41 dario NetworkManager: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'home-net'.
Jan 26 04:24:41 dario NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Jan 26 04:24:41 dario NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Jan 26 04:24:41 dario NetworkManager: <info> (wlan0): device state change: 5 -> 7
Jan 26 04:24:41 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:41 dario NetworkManager: <info> Activation (wlan0) Beginning DHCP transaction.
Jan 26 04:24:41 dario NetworkManager: <info> dhclient started with pid 9155
Jan 26 04:24:41 dario NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Jan 26 04:24:41 dario NetworkManager: <info> DHCP: device wlan0 state changed (null) -> preinit
Jan 26 04:24:45 dario NetworkManager: <info> DHCP: device wlan0 state changed preinit -> bound
Jan 26 04:24:45 dario NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) scheduled...
Jan 26 04:24:45 dario NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) started...
Jan 26 04:24:45 dario NetworkManager: <info> address 192.168.13.59
Jan 26 04:24:45 dario NetworkManager: <info> prefix 24 (255.255.255.0)
Jan 26 04:24:45 dario NetworkManager: <info> gateway 192.168.13.1
Jan 26 04:24:45 dario NetworkManager: <info> nameserver '192.168.13.1'
Jan 26 04:24:45 dario NetworkManager: <info> nameserver '66.93.87.2'
Jan 26 04:24:45 dario NetworkManager: <info> nameserver '216.231.41.2'
Jan 26 04:24:45 dario NetworkManager: <info> domain name 'dodds.net'
Jan 26 04:24:45 dario NetworkManager: <info> domain name 'debian.org'
Jan 26 04:24:45 dario NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jan 26 04:24:45 dario NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) complete.
Jan 26 04:24:45 dario NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Jan 26 04:24:46 dario NetworkManager: <info> (wlan0): device state change: 7 -> 8
Jan 26 04:24:46 dario NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 26 04:24:46 dario NetworkManager: <info> Policy set 'Auto home-net' (wlan0) as default for routing and DNS.
Jan 26 04:24:46 dario NetworkManager: <info> Activation (wlan0) successful, device activated.
Jan 26 04:24:46 dario NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.

Revision history for this message
Steve Langasek (vorlon) wrote :

Here is the profile that was added to /etc/NetworkManager/system-connections, with the WEP key elided.

Revision history for this message
Alexander Sack (asac) wrote :

reproducible for me with ifupdown plugin in managed=false mode and having auto eth0 config in /etc/network/interfaces (ENI); using managed=true in /etc/NetworkManager/nm-system-settings.conf or removing the auth eth0 configuration from ENI works around this for me.

Changed in network-manager (Ubuntu):
assignee: nobody → asac
importance: Undecided → Medium
milestone: none → ubuntu-9.04
status: New → Triaged
Revision history for this message
Steve Langasek (vorlon) wrote :

I finally noticed something in my logs with the current version of NM that explains why I've never been able to get my connection to work as a system connection.

Mar 26 00:58:01 dario nm-system-settings: Ignorning insecure configuration file '/etc/NetworkManager/system-connections/Auto home-net'

And why does it think it's insecure? Ah, because it's world-readable...

Attached is a patch that will fix this, and also fix the misspellings of 'Ignoring'...

Revision history for this message
Alexander Sack (asac) wrote :

the problem with allowing world readable keyfiles is that secrets go in the same file, so the current behaviour is intended behaviour from what i see.

Revision history for this message
Steve Langasek (vorlon) wrote :

The behavior may or may not be intented; regardless, I assert that it is incorrect.

It is not for Network Manager to dictate security policy for files that I have created. The file exists on the system already, so any information leak to other users *has already happened*. If Network Manager wants to enforce permissions on system configs when it /writes/ them, then that's ok with me, but it should not attempt to enforce security *on behalf of the wireless network*, which is not its role and not my concern as a user who created this file.

This is a usability problem introduced by inappropriate pseudo-security measures in Network Manager.

Revision history for this message
Steve Langasek (vorlon) wrote :

BTW, yes, the system config in question does have a WEP secret in it - that's the whole reason I had to create a system level config, in order to get my network connection to come up prior to login.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 321442] Re: "system"-level connection doesn't start up until nm-applet is launched

On Fri, Jun 26, 2009 at 09:29:33PM -0000, Steve Langasek wrote:
> The behavior may or may not be intented; regardless, I assert that it is
> incorrect.
>
> It is not for Network Manager to dictate security policy for files that
> I have created. The file exists on the system already, so any
> information leak to other users *has already happened*. If Network
> Manager wants to enforce permissions on system configs when it /writes/
> them, then that's ok with me, but it should not attempt to enforce
> security *on behalf of the wireless network*, which is not its role and
> not my concern as a user who created this file.
>
> This is a usability problem introduced by inappropriate pseudo-security
> measures in Network Manager.
>

I actually agree. I think NM shouldnt enforce any security on it; I
will check with upstream about the (non-)sense of this.

 - Alexander

Revision history for this message
Sam Briesemeister (sam-briesemeister) wrote : Re: "system"-level connection doesn't start up until nm-applet is launched

I'm seeing the same behavior as Steve initially described.

We need network to be available as early as possible (before login), preferably pre-GDM, but we need wireless and such as provided by NM.

Is it possible (i.e. a simple way) to activate any/all system connections before NM Applet is launched?

Revision history for this message
Alexander Sack (asac) wrote :

Sam, did you read the bug? Check that your file is not world readable/writable.

Steve Langasek (vorlon)
summary: - "system"-level connection doesn't start up until nm-applet is launched
+ NM ignores "system"-level connections if files are world-readable
Revision history for this message
Sam Briesemeister (sam-briesemeister) wrote :

Alex,

I did check that. Permissions were 0600, owned by root.

When I first read it, the bug's summary/title indicated it related more to NM Applet triggering system connections, such that they weren't available pre-login. That would be the aspect I'm most interested in.

If this bug is more specifically focused on the permissions, I'll find (or file) another one.

I will also stay quiet until I've further examined the problem I'm seeing here, so I can come back with more information if needed... ;)

Revision history for this message
Daniel Burton (lordofthebrambles) wrote :

I can confirm that this bug is not related to permissions issues. I am having the same problem on my system. When I attempt to make a connection available to all users, it disappears from the connection editor, and then a file with the connection name appears in /etc/NetworkManager/system-connections. That connection never appears in the connection editor again, and I can't activate it in the Gnome network manager applet. This happens whether the connection I create is wired or wireless.

My /etc/NetworkManager/system-connections looks like this:

-rw------- 1 root root 550 2009-07-26 20:25 Auto Burton
-rw------- 1 root root 298 2009-07-26 20:42 Auto eth0
-rw------- 1 root root 284 2009-07-26 20:27 Auto eth1
-rw------- 1 root root 297 2009-07-26 20:45 Auto eth2
-rw------- 1 root root 303 2009-07-26 21:22 Foobar
-rw------- 1 root root 307 2009-07-26 21:22 Foobar2
-rw------- 1 root root 324 2009-07-26 20:46 Wired connection 1

As you can see here, I created connections called Foobar, Foobar2, and Wired connection 1. These all disappeared when I attempted to make them available to all users.

In addition, when I attempted to edit an existing connection, Auto eth0, and reconfigure to use a zeroconf local network, it disappeared from the connection editor as well, and I couldn't enable the connection. I still can't figure out how to get Auto eth0 back. (Wired connection 1 was the result of my initial attempt to recreate a wired connection for the interface eth0. After this, I confirmed the problem by creating connections called Foobar and Foobar2.)

Revision history for this message
Steve Langasek (vorlon) wrote :

No, you are having a *different* bug. Stop conflating your issue with my bug, and open a new bug report.

Revision history for this message
Daniel Burton (lordofthebrambles) wrote :

The issues I am experiencing do not look like an entirely separate bug to me. They appear to be a variation on this bug.

The behavior on my system is exactly the same as described in the initial bug report, except that, rather than only coming up once a user has logged in, the connection does not come up at all. The only other difference is that there is no permissions issue. In addition, I tried creating wired connections as well as wireless ones, and the results were the same.

Other than that - the steps I took in creating a wireless connection that was available to all users were exactly the same. After doing so, the connection disappeared from the list of known wireless networks, and a file appeared in /etc/NetworkingManager/system-connections, exactly as described in the initial bug report (that file is "Auto Burton" on my system).

Let's let the developers determine whether this is a separate bug or the same bug. Can the bug assignee please comment on whether or not I should open a new bug report for my issues?

Revision history for this message
Steve Langasek (vorlon) wrote :

I am a developer, the bug submitter, and the author of the patch that fixed the issue I was experiencing. If you aren't seeing a log message about an insecure configuration file, and if your configuration file is only readable by root, you should file a separate bug instead of judging it the same based on the end symptom.

Revision history for this message
Daniel Burton (lordofthebrambles) wrote :

No problem, I have opened a new bug report for my issue. It is Bug 405413.

Revision history for this message
Alexander Sack (asac) wrote :

... so Dan says he would like to rather log that you have a config file created by hand and need to adjust the permissions. would that resolve your usability issue?

Dan agrees with you that the current behaviour is wrong, but thinks that users manually creating config files can be expected to read logs ... and using NM applet will not create files with wrong permissions.

some log snippets:

22:22 < dcbw> if we dont' log errors reading connections (which I dont' think we do) then of course we should fix that so users have a clue
22:23 < dcbw> basically, just because the file is already on the system doesn't mean NM should just accept it and allow it to continue being on the
              system in an insecure manner
22:24 < dcbw> and if NM rejects it, then the user who added the keyfile now knows that it's insecure immediately

Martin Pitt (pitti)
Changed in network-manager (Ubuntu):
assignee: Alexander Sack (asac) → nobody
milestone: ubuntu-9.04 → none
Revision history for this message
cheater (cheater00) wrote :

bear in mind ssh has the same policy about ignoring "insecure" files. A suggestion is to put the keys in separate files.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 321442] Re: NM ignores "system"-level connections if files are world-readable

On Sat, Aug 24, 2013 at 07:18:20AM -0000, cheater wrote:
> bear in mind ssh has the same policy about ignoring "insecure" files.

Incorrect. ssh has a policy of disallowing insecure files on the *server*
side: insecure permissions on the .ssh directory of the target user mean the
server cannot trust the integrity of those files. But that does not prevent
ssh from using a world-readable identity file on the *client* side, which is
the security equivalent of what we're talking about here.

The reason for this is that sometimes the client really *does* want the
private key to be shared, and ssh shouldn't get in the way of that; and once
the file has been made public any other user can copy it to a mode 0600
file of their own and use it there: the cat's already out of the bag, so
there's no point in trying to enforce "security" on the client.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.