On 30.03.2022 11:11, David Sommerseth wrote:
On 30/03/2022 10:51, David Sommerseth wrote:
On 29/03/2022 21:29, Timo Rothenpieler wrote:
---
This patch sits on top of the current dco branch, and will not apply to
latest master.

It solves the issue of dropping root privileges breaking dco and sitnl
due to missing NET_ADMIN capabilities.


  configure.ac           |  3 ++
  src/openvpn/init.c     | 22 +++++++++++++-
  src/openvpn/platform.c | 65 +++++++++++++++++++++++++++++++++++++++++-
  src/openvpn/platform.h |  2 +-
  4 files changed, 89 insertions(+), 3 deletions(-)


Thanks a lot!  I've quickly looked through the code, and I have to NAK this approach:

+#ifdef HAVE_LINUX_CAPABILITIES
+#define SET_CAP_HELPER(data, set, cap) data[(cap)>>5].set |= 1<<((cap)&31)
+
+static bool
+do_keep_caps(bool prepare)
+{
+    struct __user_cap_header_struct cap_hdr = { _LINUX_CAPABILITY_VERSION_3 }; +    struct __user_cap_data_struct cap_data[_LINUX_CAPABILITY_U32S_3] = {};
+
+    if (syscall(SYS_capget, &cap_hdr, cap_data) < 0)

We should really use libcap or libcap-ng and not avoid using syscalls directly.

Is there any preference between the two? I initially used libcap, but wanted to avoid introducing another dependency. But both libcap and libcap-ng seem to be widely adopted by distros, and there isn't a huge difference in boilerplate between them for this purpose.

This did not come out well.  Sorry about that.

We should really avoid using syscalls directly, as that binds us to certain APIs and bindings.

Newer kernels may also require additional adjustments in the future, to preserve the same behaviour.  Which means we need to maintain this code and also pay more attention to the security aspects of privilege management, like new vulnerabilities and exploits.

The libcap or libcap-ng libraries are used by far more applications, doing similar privilege management - and these libraries already pay attention to the security aspects of new vulnerabilities and exploits. The libcap-ng library is also recommended by more developers, due to its simpler API.

It is possible to argue that sitnl does low-level calls to the kernel as well.  But potential libraries had an API which was making everything far more complex on the OpenVPN side.  For libcap-ng at least, that is not the case; as the API it provides is pretty simple.

Shouldn't caps support also be enabled when sitnl is in use?
Given it also needs CAP_NET_ADMIN.



_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to