Problem: net-misc/vpnc-0.5.3_p527 doesn't connect to server with dev-libs/libgcrypt-1.5.2[caps] (the "caps" USE flag was added yesterday, by the way): ---- # vpnc /etc/vpnc/vpnc.conf --debug 3 vpnc version 0.5.3 hex_test: 00010203 S1 init_sockaddr [2013-04-28 21:41:02] S2 make_socket [2013-04-28 21:41:03] vpnc: Error binding to source port. Try '--local-port 0' Failed to bind to 0.0.0.0:500: Permission denied ## Try an unprivileged port # vpnc /etc/vpnc/vpnc.conf --debug 3 --local-port 10942 vpnc version 0.5.3 hex_test: 00010203 S1 init_sockaddr [2013-04-28 21:41:59] S2 make_socket [2013-04-28 21:42:00] S3 setup_tunnel [2013-04-28 21:42:00] using interface vpnc: can't initialise tunnel interface: Operation not permitted ---- With dev-libs/libgcrypt-1.5.2[-caps] it works correctly. I did a bit debugging, and found vpnc calls "gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);" immediately after it starts, but this command, according to libgcrypt manual, drops privileges of the process. If libgcrypt is compiled without caps support, it will only drop the privileges for setuid processes, which doesn't affect vpnc because it runs as root directly. Nonetheless, when it's compiled with caps support, it drops the privileges with libcap, causing vpnc to lose the privilege to bind to privileged ports, establish a tunnel, etc., therefore entirely breaking its operation. Suggested solution: The most direct way to let vpnc depends on || ( >=dev-libs/libgcrypt-1.5.2[-caps] <dev-libs/libgcrypt-1.5.2 ). I don't know if patching libgcrypt will help, but it could cause security issues, and will affect other software using the library as well. On the vpnc side, my guess is vpnc at least relies pretty much on root privileges until the tunnel is established and the up script is executed, and vpnc may require those libgcrypt things for establishing the tunnel. I tried moving the GCRYCTL_INIT_SECMEM line into the later stages of vpnc's operation, only to see a different "Operation not permitted". I didn't look further and I do not know if vpnc actually needs SECMEM. Of course, it's better to let the upstream works on the issue, but I'm not completely sure if the upstream is alive. And libcrypt already has caps support since 2003, so the problem probably has been there for ages without a fix from upstream. Reproducible: Always
Confirmed
Thanks for all your debugging. I added the workaround and will report upstream. + 01 May 2013; Justin Lecher <jlec@gentoo.org> vpnc-0.5.3_p527.ebuild: + Do not allow caps support for libgcrypt, #467744 +
Quoting upstream Digging with google, one possible solution is by stop using secure memory and use the standard allocator: - gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0); + gcry_control(GCRYCTL_DISABLE_SECMEM); This could have drawbacks in terms of security. Need deeper investigation. But keep in mind this is without support on the security side.
(In reply to comment #3) > Quoting upstream > > Digging with google, one possible solution is by stop using secure > memory and use the standard allocator: > - gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0); > + gcry_control(GCRYCTL_DISABLE_SECMEM); > This could have drawbacks in terms of security. Need deeper investigation. > > > But keep in mind this is without support on the security side. Thanks for reporting it upstream. Yeah, I could confirm the trick works in my brief test with net-misc/vpnc-0.5.3_p527. The things below should directly be reported to upstream, but I subscribed to its mailing list only just now and don't really know how to reply to a message that I didn't receive... Sorry. I think it would be possible to maintain a static copy of libgcrypt, but it could be a bit overkill for this little issue in my eyes, considering probably nobody except us has encountered this so far. With my severely limited comprehension of the situation, what I could see regarding libgcrypt's secure memory implementation are: 1. Secure memory is (usually) allocated via mmap() with MAP_PRIVATE | MAP_ANONYMOUS (src/secmem.c, init_pool()), while standard memory seemingly are allocated from the heap with malloc(). 2. They are locked into memory (never swapped into disk) via mlock() (src/secmem.c, lock_pool()). Indeed, once something gets written into a traditional hard drive, it's often recoverable in the hands of an expert. 3. Secure memory are guaranteed to be overwritten with zero when freed (src/secmem.c, _gcry_secmem_free_internal()). For a casual user (like me, who uses VPN as a tunnel to get around the Great Firewall of China) I don't think this is too huge an issue, but it could very well be a bad thing for others who uses it to access private LANs. I might be able to provide a Cisco VPN account for testing, but only during very limited hours in a day, if he really really can't find a better way to test this.
Here is the archive: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2013-May/thread.html Thanks a lot for efforts in this case and please start the discussion with the upstream devs. As a side note, having a statically, and in worst case bundled, libgcrypt is not an option from the gentoo packaging guideline perspective.
Hello, Not that it is completely related... but I am running vpnc completely as non-root... and very happy... Patches are at [1]. Instructions[2][3]. Wonderful opportunity to try out to bypass this caps issue. Alon [1] https://github.com/alonbl/alon-barlev-overlay/tree/master/net-misc/vpnc [2] http://en.gentoo-wiki.com/wiki/Vpnc_Non_Root [3] http://webcache.googleusercontent.com/search?q=cache:KUyxt3kwqAoJ:en.gentoo-wiki.com/wiki/Vpnc_Non_Root+&cd=2&hl=en&ct=clnk&lr=lang_en
+ 05 Jun 2013; Justin Lecher <jlec@gentoo.org> vpnc-0.5.3_p527.ebuild: + Drop USE=-caps restriction for libgcrypt as it was removed, #472392; this + also make #467744 obsolete +
