hooking netctl into pass for WPA2 Enterprise

fivre · 2016-10-26 23:18:37

I'm setting up WPA2 Enterprise with netctl/wpa_supplicant. I currently have the following working, but that requires storing the password on disk:

# /etc/netctl/profile 
Description='foo'
Interface=wlp4s0
Connection=wireless
Security=wpa-config
ESSID=foo
WPAConfigFile=/etc/wpa_supplicant/wpa_supplicant.conf
IP=dhcp

# /etc/wpa_supplicant/wpa_supplicant.conf
network={
    ssid="foo"
    key_mgmt=WPA-EAP
    eap=TTLS
    ca_cert="/etc/cert/wifi-certchain.pem"
    # Phase 2 / inner authentication
    phase2="auth=PAP"
    identity="<username>"
    password="<password>"
    priority=1
}

Ideally I'd like to do so without having the password stored on disk unencrypted. I do use pass for password management generally, but don't know how I'd be able to hook it into netctl. Has anyone else done so successfully? Ideally I'd be able to have it start at boot time, but it's not critical--if necessary having to start wifi after boot so I can enter the passphrase in the normal pass GUI passphrase dialog would be fine.

Leonid.I · 2016-10-27 00:17:42

TL;DR: There is no way to do what you want.

What is exactly an issue with sstoring password in a file whose permissions are 600 root:root? Any malicious root process can capture your keystrokes anyway or trojan the wpa_supplicant binary... if you need more interactive way, use networkmanager. IIRC, it stores passwords hashed in your home directory. Of course, it is insecure, but hey, at least it's hashed

fivre · 2016-10-27 03:57:35

What's the not TL;DR version of why there's no reason to do what I want?

The file is 600 root:root, and the disk is encrypted. This is less about malicious processes on the machine itself and more about a hypothetical worst-case physical security breach, i.e. some idiot left the machine unlocked with an open root terminal. You don't want that to ever happen, but it can because humans are fallible. In that scenario, requiring the additional password store passphrase that said idiot only has in their brain to decrypt the password on disk prevents a compromise.

I would think netctl hook could somehow run pass, and that pass then does it's normal thing to request the passphrase, validate it, decrypt the secret, and output the secret into a pipe back into netctl's hook, but I could be wrong. If I am wrong, I'd like to know the actual technical reason that's not possible. Simply saying "it's not possible because it's not possible" is begging the question.

Last edited by fivre (2016-10-27 03:58:38)

basica · 2016-10-27 04:33:31

I think you might be able to do what you're after. A google search turned up this. Perhaps this can give you some insight as to how you can implement what you're after?

Leonid.I · 2016-10-28 05:20:27

fivre wrote:

What's the not TL;DR version of why there's no reason to do what I want?
The file is 600 root:root, and the disk is encrypted. This is less about malicious processes on the machine itself and more about a hypothetical worst-case physical security breach, i.e. some idiot left the machine unlocked with an open root terminal. You don't want that to ever happen, but it can because humans are fallible. In that scenario, requiring the additional password store passphrase that said idiot only has in their brain to decrypt the password on disk prevents a compromise.

If you leave your machine unlocked with root logged in, an attacker can do anything, like subverting your password manager. Then not only your wpa passphrase, but your master password are stolen. Said idiot should not be trusted with an admin passwd to begin with.

fivre wrote:

I would think netctl hook could somehow run pass, and that pass then does it's normal thing to request the passphrase, validate it, decrypt the secret, and output the secret into a pipe back into netctl's hook, but I could be wrong. If I am wrong, I'd like to know the actual technical reason that's not possible. Simply saying "it's not possible because it's not possible" is begging the question.

Netctl is a non-interactive system service. To accomplish what you want, one would somehow tell systemd to interrupt boot and wait for your input. Which uid should pass be running as, root? What if the passwd store is located on a device that has not been mounted yet (e.g. NFS, or some autofs-managed filesystem)? See, how ugly it gets... Of course, nothing is impossible and you should be able to hack smth together. But this is going to be very specific to your setup, and mostly likely introduce more security issues than it solves. There are many interactive network managers, if you need them. Netctl just isn't one of them.

In summary, if you don't trust your root account, then you can't trust any code running on the machine. If you do, however, then DAC provides adequate protection of your passphrase. And before you ask, no, storing the passwd encrypted in wpa_supplicant.conf and decrypting it inside the wpa_supplicant daemon won't work either. To understand why, read the section "Password encryption in .fetchmailrc" at http://www.catb.org/~esr/fetchmail/design-notes.html .

Last edited by Leonid.I (2016-10-28 05:23:02)

Arch Linux

#1 2016-10-26 23:18:37

hooking netctl into pass for WPA2 Enterprise

#2 2016-10-27 00:17:42

Re: hooking netctl into pass for WPA2 Enterprise

#3 2016-10-27 03:57:35

Re: hooking netctl into pass for WPA2 Enterprise

#4 2016-10-27 04:33:31

Re: hooking netctl into pass for WPA2 Enterprise

#5 2016-10-28 05:20:27

Re: hooking netctl into pass for WPA2 Enterprise

Board footer