Closed major closed 7 months ago
Now I'm trying to understand the code flow around here as well....
Looks like mount.efs
can launch stunnel
, but that then the watchdog can also do that, so you end up with a bit of a weird situation as to how the tunnel could be running (and indeed from the look of the code, two places that can set it up).
It's plausible there's a much simpler way to achieve the stunnel
and watchdog functionality would be with a templated systemd
service, along with the systemd
watchdog functionality? Thus mount.efs
could kick that off in the common case?
@stewartsmith That's a good idea (using systemd
for the heavy lifting). I wonder if we could do some type of parameterized unit file (I forget what they're called) such as efs-stunnel@[identifier]
just as we would with systemctl start wg-tools@wg0
. 🤔
I would imagine that it would be a little easier to just let systemd manage all those pids and such.
@stewartsmith Unfortunately, this is a blocker for me with RHEL inclusion because I cannot add a package with an unconfined daemon. 😭
Do you think a little rework of the process stack is possible here?
Nevermind! We got efs-utils working with SELinux contexts in Fedora now. https://src.fedoraproject.org/rpms/efs-utils/tree/rawhide
I maintain the efs-utils package in Fedora and I'm working to bring it into Red Hat Enterprise Linux. However, I would like to avoid running the watchdog daemon and stunnel process unconfined. Moving it into a confined SELinux context would be a security improvement.
However, when the watchdog spawns an stunnel process for an encrypted EFS mount, the stunnel process has no parent. This makes SELinux confinement difficult because a policy matching
stunnel
would end up confining other uses of stunnel on the system outside of EFS.Based on reading the comments in the watchdog, it makes sense that a watchdog process being a parent of the stunnel process could potentially be problematic, especially if the watchdog process is restarted. It would take down the stunnel process and bring it back up, which would disrupt the filesystem mount.
Are there any possibilities here of allowing the watchdog daemon to be the parent process of the stunnel processes it creates? This would make SELinux confinement a bit easier and would make it clear in the process list where these stunnel processes came from.
Thanks!