Hello,
I would like to forward to you a bug report I received
(https://bugs.gentoo.org/show_bug.cgi?id=467744):
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.
Do you see any chance to fix this issue?
Regards,
Justin
I would like to forward to you a bug report I received
(https://bugs.gentoo.org/show_bug.cgi?id=467744):
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.
Do you see any chance to fix this issue?
Regards,
Justin