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.