To drop selinux privileges, you need to create a selinux domain with
less privileges then the original openvpn domain, and allow the original openvpn domain to
dyntransition to this new selinux domain with less privileges.
The question here is: Which selinux privileges can be dropped?
The domain I am trying to get to is not different from the one openvpn
is running on - the difference is the user (unconfined_u as oppose to
system_u) - the rest is exactly the same - openvpn_t. So, in short - the
transition is from unconfined_t:system_r:openvpn_t ->
system_u:system_r:openvpn_t. I don't know SELinux enough to judge
whether that is a big 'drop' or if it presents a major risk if I run it
in "unconfined_u:system_r:openvpn_t", but if it doesn't that I may drop
the --selcon option and leave openvpn to run in
unconfined_t:system_r:openvpn_t.
Your other issue is your scripts. Currently it seems that these
scripts probably run in the openvpn domain. Thus with the openvpn user privileges and the
openvpn selinux privileges.
That is correct!
From an selinux point of view that means your scripts can leak to
openvpn and vice versa.
The alternative is to leave openvpn to run as root (and be able to
execute the scripts as root without further difficulties), but I am not
sure that is a good idea! Leaving openvpn to execute /sbin/ip directly
is out of the question!
You could create selinux domains for each script and extend openvpn
policy to allow openvpn to transition to each scripts selinux domain, when openvpn runs
the script.
Is that done with init_daemon_domain()?
That leaves us with the sudo issue. This is only an issue for scripts
run as non-root (so for scripts run from the openvpn rc script this is no issue)
That means that the selinux domain for the scripts that do not run as root need to be
allowed to run sudo i guess (i still think thats a bad idea but so be it)
So all-in-all a lot of work to do:
1. create a openvpn selinux domain for openvpn to drop to:
- which selinux permissions can be dropped?
2. create selinux domains for each of your scripts and allow openvpn or init to domain
transition to them.
- allow the scripts started by openvpn to run sudo to gain privileges.
The question is: can all this work be justified?
How much work would that be - I am no SELinux expert, but thought that
apart from the dyntransition and the other openvpn-related AVC (which
will be gone if I do not use the --selcon option) the rest are simple
exec file privileges, which if granted, then will make the whole issue
go away. I might be wrong though.
There is one other thing though - openvpn_t is trying to execute
sudo_exec_t. I wonder if sudo_exec_t does have these privileges and I
just need to transition to this domain (if at all)?
I can help you implement it but i warn you that it will require much
testing and i am not sure if it will benefit security that signicantly.
I am not afraid of testing, though I am not convinced that running
openvpn as root (even in the openvpn_t domain) is a good idea either!
As far as sudo goes - if there are alternative ways which give me proper
security and allow me to execute /sbin/ip safely, I will gladly accept
those - no question!