Join Log in
Score:3
cyqsimon avatar Server

OpenVPN server - does dropping previleges affect accessing files at runtime?

ck flag
cyqsimon

In OpenVPN's hardening article, it is recommended that the server daemon drop its privileges after startup on Linux:

OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.

They recommend that the following directives be set:

user nobody
group nobody

which I assume mean that the daemon will be running as nobody after startup is complete.

However, there are several files that OpenVPN accesses at runtime, notably the CRL file:

When the crl-verify option is used in OpenVPN, the CRL file will be re-read any time a new client connects or an existing client renegotiates the SSL/TLS connection (by default once per hour). This means that you can update the CRL file while the OpenVPN server daemon is running, and have the new CRL take effect immediately for newly connecting clients.

So naturally I'm worrying if those two features are incompatible - if the daemon drops privileges after startup, how can it read /etc/openvpn/server/crl.pem (owner root:root, mode 0600; SELinux enforcing) at runtime?

  • If the daemon is indeed unable to access the CRL file at runtime, is there a good way to circumvent this problem?
  • If the daemon can access the CRL files at runtime, I would like to know how this is possible.

OS is RHEL8.5 x86_64 in case that's relevant.

39
0 + 0
Score:2
avatar Server
et flag
SmallClanger

Like a lot of applications that drop privileges, OpenVPN opens various file handles while it still has root, which then persist. Once it has dropped privs, the process is still able to access those handles in the mode they were opened with, for as long they remain open.

A compromise of the openvpn process wouldn't expose the file to changes in this case, because the file is (likely, I haven't checked) opened read-only. A new file handle would be required to open it in write mode, which would fail as the process can no longer create one.

0 + 0
cyqsimon avatar
ck flag
cyqsimon
Ah thank you. This makes sense. Is there an official source where this behaviour is documented? Or is this behaviour so commonplace that it has essentially become idiomatic and not worthy of documenting?
0
Reply
et flag
SmallClanger
I guess the only _official_ source is the actual source code as it's your only true guide to what's really happening. If you're looking to _understand_ more, then perhaps start with the wiki/man pages on [file descriptors](https://en.wikipedia.org/wiki/File_descriptor) and the [open() system call](https://man7.org/linux/man-pages/man2/open.2.html). Once you grok that permissions checks are performed _at those system calls_, this all makes more sense :)
2
Reply
my flag
chicks
Dropping privs after opening priv'd ports is definitely a widespread best practice for old school *nix daemons like openvpn and bind. I'm not sure of an authoritative reference for this habit.
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.