sudo in learn-address-script fails to run commands with 2.6-rc #220
Comments
|
The security aspects in OpenVPN 2.6 has been hardened quite a bit further. So we're dropping more privileges by design. The appropriate way to do this within newer Linux distributions is to make use of polkit (formerly known as PolicyKit). There is a tool here called |
|
So I took the extra mile and replaced to "sudo" calls with "/usr/bin/pkexec" and created some nft related policies and rules: /usr/share/polkit-1/actions/nft.policy: /etc/polkit-1/rules.d/nft.rules: And while this works on the console: it's not working inside openvpn itself: |
|
For kicks I reverted to 2.5.8 with pkexec in the scripts -- that works flawlessly. |
|
Hi,
On Mon, Jan 16, 2023 at 01:07:25AM -0800, David Sommerseth wrote:
The appropriate way to do this within newer Linux distributions is to make use of polkit (formerly known as PolicyKit). There is a tool here called [`pkexec`](https://polkit.pages.freedesktop.org/polkit/pkexec.1.html) which is far better suited to handle privilege escalation from scripts like your use case.
How can pkexec do that if setuid capability is gone? Does it use some
sort of dbus daemon-invocation mechanism?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
Yes, @cron2 , it kicks off a new process with more privileges if the polkit policy grants that access. I don't recall now exactly how deeply tied this is to D-Bus itself, but it is a common way to run certain commands with more privileges. That's the theory at least 🙂 |
Well, @hildeb and I can now say: pkexec cannot do it; when setuid is gone, pkexec does not work as well for these purpose. (Logline As this security-tightening change is breaking things, it should get noted in https://github.com/OpenVPN/openvpn/blob/master/Changes.rst#common-errors-with-openssl-30-and-openvpn-26 |
|
@hildeb Can you try updating your polkit pkexec policy to run a script instead, which dumps a |
|
With 2.5.8: With 2.6rc2: |
|
Output was generated by: |
|
I've poked a little bit at the code. I see that the "Bounding set" is empty in OpenVPN 2.6rc2, which I believe is the crux of the issue. That said, it might just need a few more tweaks and not just reverting the capabilities changes (commit 2e359a0). It will be needed to go deeper into the openvpn/src/openvpn/platform.c Line 249 in 39dd79d openvpn/src/openvpn/platform.c Line 239 in 39dd79d |
|
From all I understand, just dropping the CAPNG_CLEAR_BOUNDING flag should bring it back to the old behaviour. |
BtbN
added a commit
to BtbN/openvpn
that referenced
this issue
Jan 18, 2023
The bounding set being empty will overpower the likes of su/sudo and will make it impossible for any child-processes to ever gain additional privileges again. This should fix OpenVPN#220 Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
I've pushed a patch that does so to https://github.com/BtbN/openvpn if you want something to grab and build for testing. |
|
We rebuilt a ubuntu openvpn-rc2 package with this patch applied, and yay,
it works...
For our metric of what "works" means :)
Jan 18 15:18:52 localhost openvpn[49487]: ---- raw caps
Jan 18 15:18:52 localhost openvpn[49487]: Current: =
Jan 18 15:18:52 localhost openvpn[49487]: Bounding set
=cap_dac_override,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_audit_write
Jan 18 15:18:52 localhost openvpn[49487]: Ambient set =
Jan 18 15:18:52 localhost openvpn[49487]: Current IAB:
!cap_chown,!cap_dac_read_search,!cap_fowner,!cap_fsetid,!cap_kill,!cap_linux_immutable,!cap_net_broadcast,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_control,!cap_setfcap,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore
Jan 18 15:18:52 localhost openvpn[49487]: Securebits: 00/0x0/1'b0
Jan 18 15:18:52 localhost openvpn[49487]: secure-noroot: no (unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-no-suid-fixup: no
(unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-keep-caps: no (unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-no-ambient-raise: no
(unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: uid=996(openvpn) euid=996(openvpn)
Jan 18 15:18:52 localhost openvpn[49487]: gid=996(openvpn)
Jan 18 15:18:52 localhost openvpn[49487]: groups=
Jan 18 15:18:52 localhost openvpn[49487]: Guessed mode: UNCERTAIN (0)
Jan 18 15:18:52 localhost openvpn[49487]: raw caps ----
and
Jan 18 15:18:52 localhost openvpn[49487]: ---- pkexec caps
Jan 18 15:18:52 localhost openvpn[49487]: Current:
cap_dac_override,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_audit_write=ep
Jan 18 15:18:52 localhost openvpn[49487]: Bounding set
=cap_dac_override,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_audit_write
Jan 18 15:18:52 localhost openvpn[49487]: Ambient set =
Jan 18 15:18:52 localhost openvpn[49487]: Current IAB:
!cap_chown,!cap_dac_read_search,!cap_fowner,!cap_fsetid,!cap_kill,!cap_linux_immutable,!cap_net_broadcast,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_control,!cap_setfcap,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore
Jan 18 15:18:52 localhost openvpn[49487]: Securebits: 00/0x0/1'b0
Jan 18 15:18:52 localhost openvpn[49487]: secure-noroot: no (unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-no-suid-fixup: no
(unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-keep-caps: no (unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: secure-no-ambient-raise: no
(unlocked)
Jan 18 15:18:52 localhost openvpn[49487]: uid=0(root) euid=0(root)
Jan 18 15:18:52 localhost openvpn[49487]: gid=0(root)
Jan 18 15:18:52 localhost openvpn[49487]: groups=0(root)
Jan 18 15:18:52 localhost openvpn[49487]: Guessed mode: UNCERTAIN (0)
Jan 18 15:18:52 localhost openvpn[49487]: pkexec caps ----
The firewalling scripts are able to perform their duties (again), like back
in 2.5.x
Am Mi., 18. Jan. 2023 um 14:46 Uhr schrieb BtbN ***@***.***>:
… I've pushed a patch that does so to https://github.com/BtbN/openvpn if
you want something to grab and build for testing.
—
Reply to this email directly, view it on GitHub
<#220 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AASQLWTG5WYRCEWGXWLFKQDWS7X4PANCNFSM6AAAAAAT3IQF3A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
BtbN
added a commit
to BtbN/openvpn
that referenced
this issue
Jan 18, 2023
The bounding set being empty will overpower the likes of su/sudo and will make it impossible for any child processes to ever gain additional privileges again. This fixes OpenVPN#220 Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
Great news! Thx for testing @hildeb! |
cron2
pushed a commit
that referenced
this issue
Jan 19, 2023
The bounding set being empty will overpower the likes of su/sudo and will make it impossible for any child processes to ever gain additional privileges again. Github: fixes #220 Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <20230118142428.162-1-timo@rothenpieler.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26048.html Signed-off-by: Gert Doering <gert@greenie.muc.de> (cherry picked from commit d852311)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
As we install user-specific nft-firewall-rules when the user logs into our OpenVPN-service, we need to run nftables-commands via sudo in our learn-address-scripts. When we tried to run 2.6-rc1/rc2 on Ubuntu 22.10 the scripts we used before throws the error
sudo: unable to change to root gid: Operation not permittedwhen calling the nft-binary via sudo.This mechanism runs on our production-OpenVPN-Servers (currently with 2.5.8 on Ubuntu 20.04 LTS) since years without any problem. The configuration-snippet:
While testing OpenVPN 2.6-rc1/rc2 and the behaviour with the failing sudo occurred on our Testsystem (Ubuntu 22.10, OpenVPN 2.6-rc2), the Linux-Capabilities came to our attention. So I logged, with which capabilities the script is running (using
/sbin/capsh --print):Logsnippet 2.6
Logsnippet
OpenVPN 2.6_rc2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]The same system with the same settings, downgraded to OpenVPN 2.5, works:
Logsnippet 2.5
Version:
OpenVPN 2.5.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD]So the difference between these two is the "Bounding set", where setuid/setgid was allowed in 2.5.
Maybe OpenVPN is dropping too much privileges/capabilities in 2.6? Or is this wanted behavior, as this sudo-solution could potentially lead to security-issues? (In the latter case, we would have to rewrite our firewall-setup-phase).
To Reproduce
Run any command via sudo (for becoming another user) in a learn-address-script.
Expected behavior
Run the sudo-commands as called in the learn-address-script.
Version information (please complete the following information):
The text was updated successfully, but these errors were encountered: