On 07/05/15 00:49, David Woodhouse wrote:
> On Wed, 2015-05-06 at 22:06 +0200, David Sommerseth wrote:
>>
>> All patches has been tested locally with different configurations,
>> requiring username, password and passphrases to PKCS#12 files. The
>> challenge/response interface has not been tested, as well as PKCS#11.
>> All runs via valgrind shows no memory leaks with this new
>> implementation.
>
> I've given some pointers in ticket 538 on how you can test PKCS#11
> without actually having a hardware token — you can use GNOME keyring in many
> cases, or in this case where you really want to test
> password input,
> you can use a NSS "softokn" database.
>
> Even if I make these patches build by fixing the issue that leads to
> libsystemd_MODVERSION being set to '219\n219' when both systemd.pc and
> libsystemd.pc exist, they still don't solve the problem described in
> that ticket.
>
> You are still calling fork() from a context (the PIN request callback
> from pkcs11-helper) in which it is forbidden, and in which it
> deadlocks:
>
> #2 0x00007ffff7d9c096 in _pkcs1h_threading_mutexLockAll () at
> pkcs11h-threading.c:306
> #3 0x00000038412c8362 in __libc_fork () at ../sysdeps/nptl/fork.c:89
> #4 0x0000003841a0f4a5 in __fork () at pt-fork.c:25
> #5 0x000000000042893b in openvpn_popen (a=a@entry=0x7fffffff9be0,
> es=es@entry=0x0) at misc.c:374
> #6 0x000000000046f0e8 in get_console_input_systemd (capacity=4096,
> input=0x7fffffffb1f2 "", echo=false,
> prompt=0x73cdc8 "Enter PIV_II (PIV Card Holder pin) token Password:") at
> console_systemd.c:72
> #7 query_user_exec (setup=<optimized out>) at console_systemd.c:111
> #8 0x0000000000427aed in get_user_pass_cr (up=up@entry=0x7fffffffa1f0,
> auth_file=<optimized out>, auth_file@entry=0x0,
> prefix=prefix@entry=0x7fffffff9df0 "PIV_II (PIV Card Holder pin) token",
> flags=flags@entry=21, auth_challenge=auth_challenge@entry=0x0) at misc.c:1144
> #9 0x0000000000435711 in get_user_pass (flags=21, prefix=0x7fffffff9df0
> "PIV_II (PIV Card Holder pin) token", auth_file=0x0, up=0x7fffffffa1f0) at
> misc.h:268
> #10 _pkcs11_openvpn_pin_prompt (global_data=<optimized out>,
> user_data=<optimized out>, token=<optimized out>, retry=<optimized out>,
> pin=0x7fffffffc250 "K{`f=",
> pin_max=1024) at pkcs11.c:236
> #11 0x00007ffff7d9e0cb in _pkcs11h_session_login (session=0x6e9220,
> is_publicOnly=is_publicOnly@entry=0, readonly=readonly@entry=1,
> user_data=0x0,
> mask_prompt=<optimized out>) at pkcs11h-session.c:1023
>
> Perhaps the solution might be to *always* operate in 'management
> interface' mode, and to shift all the direct console access out to a
> separate process. *That* process would be permitted to run fork(),
> when the core OpenVPN process requests a password...THanks a lot for a lot of value input, both here and in the trac ticket! I'll go through that and digest it carefully. In regards to fork()/vfork(). Personally, I'm not against changing it. However, I don't know what the other reviewers may think. I'll dig deeper into this matter and. Having that said, looking isolated on systemd and pkcs#11. I've heard from a few of the systemd developers that they are going to retire the current approach for quering for user input for something more flexible. And they point at some kind of DBus interface as a natural next step (it has not yet materialized into code, so I'm currently sitting on the fence). That means that OpenVPN would not fork at all, it would send a request via a DBus interface describing what the user (or session) must provide. And the result is then returned via DBus. And this is what I've had in mind when changing these code paths. Which is also the reason that console_systemd.c isn't compiled unless configured with --enable-systemd ... to easier split out code which may make the non-Linux guys of the openvpn community scream and panic when seeing DBus library dependencies. The current management interface works fairly well, but it has limitations which can cause some cause some hang-ups due to the single threaded nature of OpenVPN - there are also some who claims they notice performance drops when management commands are processed. I've not dug into these claims yet, but it doesn't surprise me if there is something to it. In addition the connection to the management interface is basically not authenticated (well, you can have a password but it's a clear-text connection). Again, thanks a lot for all your input! I'm fairly loaded with work, so openvpn does unfortunately suffer from that from my part. But I do appreciate your involvement! -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
