Summary: | net-misc/vpnc-0.5.3_p527 with dev-libs/libgcrypt[caps] - vpnc drops privileges too early | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Richard Grenville <pyxlcy> |
Component: | Current packages | Assignee: | Lori <lori> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, jlec, mmokrejs, ninex, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 468616 |
Description
Richard Grenville
2013-04-28 14:16:31 UTC
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 + |