[strongSwan] Two questions about swanctl.conf

[xalloc]

>Generally, you could use your own storage scheme (e.g. an encrypted
>file that's decrypted with a password entered on the console) and load
>the secrets into the daemon via VICI protocol.

Can swanctl ask interactively for the password if not inserted in the conf file?

> If you store them in swanctl.conf (or a file included by it) make sure
> it's only readable by the appropriate user (root or whatever swanctl
> will be run as).

Does this guide apply to swanctl too? Cause currently I'm root-only

https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Il lunedì 13 maggio 2019 12:33, Tobias Brunner <tobias at strongswan.org> ha scritto:

> Hi,
>
> > 1.  Is there a "more secure" way to store the per-user psk password in swanctl.conf file?
>
> First, note that shared keys will be accessible in memory once loaded
> into the daemon via VICI. So the question is whether you are concerned
> with the actual storage, or with other attack vectors.
>
> Generally, you could use your own storage scheme (e.g. an encrypted file
> that's decrypted with a password entered on the console) and load the
> secrets into the daemon via VICI protocol.
>
> Then the available options depend on the type of secret. IKE pre-shared
> keys must be available to the daemon locally. However, EAP secrets may
> be verified via RADIUS and stored on a different host (they still have
> to be available in plaintext to the RADIUS daemon there). If EAP-GTC is
> an option (many clients don't support it), the passwords may be verified
> via PAM and stored in hashed form. And for EAP-MSCHAPv2, passwords may
> be stored as MD4/NT-hashes in swanctl.conf.
>
> If you store them in swanctl.conf (or a file included by it) make sure
> it's only readable by the appropriate user (root or whatever swanctl
> will be run as).
>
> > "It is not recommended to define any private key decryption passphrases, as then there is no real security benefit in having encrypted keys. Either store the key unencrypted or enter the keys manually when loading credentials."
> > Maybe I'm misreading that sentence. I just have the plain password.
>
> That paragraph is referring to passwords used to encrypt private keys,
> not shared secrets.
>
> > 2.  In the pools section, is there a way to define the default localdomain-search variable?
>
> If you know the numeric identifier, you can use that to assign arbitrary
> configuration attributes to clients (they will just ignore it if they
> don't know/support it). There is no IKEv2 attribute type standardized
> for the search domain, though.
>
> Regards,
> Tobias