I have just started using openfortivpn to connect to a fortigate vpn. It is a standard rpm package I installed via dnf. It comes with a systems service file.
Here’s what happens:
I run fedora 32 up to date with selinux enabled
If I run the openfortivpn client manually (with sudo), it succeeds without problems
If I run it as a service via systemd, it comes up, but is unable to create routes:
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG: ip route add to 10.0.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN: Could not set route to tunnel gateway (Operation not permitted).
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG: ip route add to 10.1.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN: Could not set route to tunnel gateway (Operation not permitted).
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: DEBUG: ip route add to 10.5.0.0/255.255.255.0 dev ppp0
Jul 14 08:40:07 sv-schmidt openfortivpn[47004]: WARN: Could not set route to tunnel gateway (Operation not permitted).
The service runs as root, as I saw with ps
There are no entries in the selinux audit log
If I set selinux to permissive, the service starts and all the routes are successfully created.
again, no entries in the audit log
Now, I never run in permissive, and I don’t like the idea of starting the vpn manually.
What could be the problem? Clearly there is a permission problem, but where? Usually, I get information from the audit log, and fix it. Might there be policy via polkit required? This is a business requirement. Does anyone have an idea?
That was my next thought. From a quick google search; it doesn’t appear to be the first time its had an issue with selinux; although that was issue with updating /etc/resolv.conf
I would do as vgaetera suggests and file a bug report.
Tried both restorecon -v /etc/resolv.conf and restorecon -R -v /etc, no luck. Same thing happens. At least, for the restorecon bug, there was an AVC. I also checked the boolean openfortivpn_can_network_connect mentioned in the bug report, but it is there and set to on.
So I am coming to the same conclusion, a bug report is warranted. Thanks for your efforts on my behalf.
I don’t necessarily disagree, it’s just not clear to me who’s at fault here:
is it openfortivpn for not getting some selinux setting right,
is it a selinux policy (but then running it manually should have the same result)
is it systemd somehow initializing the process incorrectly
but what no AVC? I think the primary bug is that combination of denial and there’s no AVC
I’m not at all clear on the difference between systemd starting it as root and my starting it manually via sudo. I always thought that
this would be much the same, given the trivially simple unit file. This intrigues me alot, and I think I will have to learn more about that.
What did you do to check for AVC:s? I’m asking since I have myself been similarly confused. I used ausearch -m avc … and did not got anything. Later on, I realised there were “user AVC:s”, but they didn’t show up when I ran the above command. When I finally found out I could also run ausearch -m user_avc …, or without any -m flag at all, I got the explanation. Maybe you are hitting something similar?
Actually, I usually use audit2why or check the AVCs in cockpit. I also scan the /var/log/audit/audit.log manually. I rarely use ausearch unless I already know what I’m looking for.