The sudo policy currently only supports that sudo is run by users, not by scripts. But we could hack around that, we could run sudo in the callers domain, but that would mean that the caller domain needs the privileges to run sudo.
There is a macro in sudo.if called sudo_role_template which appears to do a similar thing. Again, my selinux knowledge is not that great to judge if it is of any use in my case.
I think in your scenario it may not make that much of a difference. Your scenario being that you have openvpn run scripts that need root. You have selinux to confine root (openvpn) if you use an unprivileged user you need to either allow openvpn to run sudo which basically pretty much negates the dropping root measure.
Well, no, because sudo is run from my scripts (not directly by openvpn) and escalating of privileges happens only during that time - while sudo executes a specific command (/sbin/ip in this case) in that specific script. For the rest of the time openvpn runs in openvpn_t AND the user is not root. Much safer!
or you have to confine your scripts so that from an selinux perspective its no longer openvpn that needs to run sudo but its your script domains.
The benefit of that would be that your scripts cannot mess with openvpn and its files.
The downside is that you need to write/maintain a few custom modules.
Being that you are not so familair with selinux and that its hard for me to guide you by using e-mail, it might be tempting to just run openvpn as root. Its protected by selinux so its not that bad.
I will look for an alternatives then as running openvpn as root does not sit well with me at all - just not going to happen.
Well i doubt it, remember that those are options, just as running scripts from openvpn is a option.
Bad design - that is what I was trying to point out. You cannot run openvpn as non-root as it needs to be (at least at some point) root in order to function properly. As I said - a lousy job!
Just because someone gains root through openvpn does not mean that he automatically has control over your system. That where selinux comes in. Even though the attacker is root, the attacker is still confined to the openvpn_t selinux domain.
Basically the attacker is stuck with just the open vpn privileges. So he could mess with open vpn and some other stuff but not the whole system.
I understand that, but it presents a loophole which could be exploited - I do not like that one single bit.
openvpn does not install /var/lib/openvpn. plus the type openvpn_etc_t is not suitable for stateful data (open vpn can read it but not write it)
Actually, it can - see the "touch $ROUTE_UP" statement in one of the scripts - it executes successfully in that directory - no problem.