Closed Grissess closed 1 month ago
Let me know if you need any further information :)
Any results, if you run
dmesg | grep audit | grep openvpn-auth-oauth2
as root?
Let me know if you need any further information :)
Any results, if you run
dmesg | grep audit | grep openvpn-auth-oauth2
as root?
Exactly nothing. I forgot to mention, as part of minor config variance, that I did install an apparmor local policy, /etc/apparmor.d/local/usr.bin.openvpn-auth-oauth2
:
/etc/openvpn/pki/* r,
/run/openvpn.sock rw,
(For TLS certificates in the testing config and the OpenVPN socket itself. The former is actually no longer required, and I might evict it soon.)
Edit: I should note that I also saw no audit logs for its failure to connect to the socket directly; a random StackOverflow answer induced me to check apparmor, where I found that installed policy. Prior to that, it was occasionally, randomly, racing with an error opening /run/openvpn.sock
; now it only fails in the described manner.
apparmor local policy
should the /etc/openvpn-auth-oauth2 path not included?
apparmor local policy
should the /etc/openvpn-auth-oauth2 path not included?
Oh, that's included from the base policy:
root@vpn-host:~# cat /etc/apparmor.d/usr.bin.openvpn-auth-oauth2
# vim:syntax=apparmor
abi <abi/3.0>,
include <tunables/global>
/usr/bin/openvpn-auth-oauth2 flags=(attach_disconnected) {
include <abstractions/base>
include <abstractions/nameservice>
@{etc_ro}/openvpn-auth-oauth2/** r,
@{run}/openvpn{,-server}/* rw,
@{sys}/kernel/mm/{hugepages,transparent_hugepage}/{,**} r,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/usr.bin.openvpn-auth-oauth2>
}
I'm assuming that was installed by the package, and does include @{etc_ro}/openvpn-auth-oauth2/** r
:)
That's indeed necessary--per recommendation, I broke out some of the secrets into restrictively-moded files in /etc/openvpn-auth-oauth2
, and refer to them using file://
URLs (with absolute paths).
I guess the issue must be in some of the over-engineered systemd properties that I had enabled. systemd uses namespaces and secomp to restrict file access.
Maybe something in 24.04 works differently.
I'll happily await some tests; if you need this system to test some theories/fixes, I proffer it :)
Good luck!
I'll happily await some tests; if you need this system to test some theories/fixes, I proffer it :)
Good luck!
While I have access to free resources at Azure (e.g. VMs), I'm in vacation at least for one week until next saturday.
no worries, then, take your time :)
In the meantime, these servers are merely running the daemon as an unprivileged user in a tmux session--it'll hold out for a little while.
Guess comment this lines out
should also resolve the issue for now
I actually tracked this down to an issue unrelated to permissions at all: it's the EnvironmentFile shipped with the project :)
# This file is sourced by the openvpn-auth-oauth2.service
# CONFIG_FILE is the path to the configuration file and used in the systemd service file only.
CONFIG_FILE=/etc/openvpn-auth-oauth2/config.yaml
# https://github.com/jkroepke/openvpn-auth-oauth2/wiki/Configuration
CONFIG_OPENVPN_ADDR=unix:///run/openvpn/server.sock
CONFIG_OAUTH2_ISSUER=https://login.microsoftonline.com/<tenant-id>/v2.0
CONFIG_OAUTH2_CLIENT_ID=
CONFIG_OAUTH2_CLIENT_SECRET=
CONFIG_HTTP_LISTEN=:9000
# Define a random value with 16 or 24 characters
CONFIG_HTTP_SECRET=
# Define the public http endpoint here.
CONFIG_HTTP_BASEURL=http://localhost:9000
Note that env vars are loaded later than config, meaning the former overrides the latter. That means this example skeleton config, with invalid values, unexpectedly overrides the user's config.yaml
in the default configuration. (As I wasn't about to use env vars, I didn't even bother to check this file.)
The easy workaround, of course, is to just comment out the lines--and it might be preferable if upstream did so, both so they're there as examples that most users will use, and to avoid this precise footgun :)
After doing so, I tested the systemd unit without any systemd-level overrides, and it seems fine.
The easy workaround, of course, is to just comment out the lines
You are right, this should be comment out by default to avoid this scenario. Are you interested in a PR?
Current Behavior
Using
systemctl start openvpn-auth-oauth2
on the provided .deb package on Ubuntu 24.04, the following logs appear insystemctl status openvpn-auth-oauth2
:Starting the service manually as
nobody
with the appropriate supplemental group works, however:Despite the failure to load config, it is opening the file and parsing it correctly, as different errors occur when the file does not exist:
or when the file is not syntactically-valid YAML:
Expected Behavior
The systemd unit should start and run successfully.
Steps To Reproduce
Environment
openvpn-auth-oauth2 logs
openvpn server logs
Anything else?
Let me know if you need any further information :)