Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#37385 - [netctl] config files created by wifi-menu are insecure, include plain text passwords
Attached to Project:
Arch Linux
Opened by Jyri Hovila (Jyri-poika) - Friday, 18 October 2013, 10:57 GMT
Last edited by Jouke Witteveen (jouke) - Sunday, 27 October 2013, 14:32 GMT
Opened by Jyri Hovila (Jyri-poika) - Friday, 18 October 2013, 10:57 GMT
Last edited by Jouke Witteveen (jouke) - Sunday, 27 October 2013, 14:32 GMT
|
DetailsDescription:
When wifi-menu is used (by root) to join a password protected WLAN network, it automatically creates a netctl profile (named /etc/netctl/<interface-name>-<network-name>). Stored in this world-readable-by-default file is the WLAN password. The user is not informed of nor asked to confirm saving of the password. Although automatic generation of the netctl config file is a good feature, it should be optional. Special care should be taken regarding storing of [clear text] passwords. Additional info: * package version: 1.3-1 Steps to reproduce: 1. Launch wifi-menu and join a password protected network as root 2. grep Key= /etc/netctl/* |
This task depends upon
Closed by Jouke Witteveen (jouke)
Sunday, 27 October 2013, 14:32 GMT
Reason for closing: Fixed
Additional comments about closing: 8a414
Sunday, 27 October 2013, 14:32 GMT
Reason for closing: Fixed
Additional comments about closing: 8a414
600 would be a lot better.
Making saving of the password optional (or at least letting the user know it is being saved) would be even better. =)
There is, however, a need for a umask in the globals. The question is what it should be. There are a few options:
077: conservative
007: allows administrative groups to mess around (more permissive for groups than the default 022)
027: something in between
Opinions?