On Sat, Sep 11, 2010 at 06:01:02PM +0100, Mr Dash Four wrote:
>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.
Its not significant the _u field does not enforce any restrictions in Fedora.
So if that is your reason to use -setcon you can can skip it.
>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.
The dyntransition no longer applies since you wanted to use it to change the selinux user
field which is insignifcant.
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)?
The issue that openvpn_t needs access is a problem. Because if openvpn_t can run sudo it
can run commands as root.
Therefore we must make sure its not openvpn_t that runs sudo but the scripts domains.
if we define domains for the script to be run in, then it is the script domain that needs
access to sudo and not openvpn_t domain.
>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!
Question is does security risk justify the work that needs to be done.
Basically you say i want openvpn to drop privileges and once it dropped privileges you
later need it to gain privileges again to run the scripts.
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!
Where are the scripts located? (make sure they are in the location where they will be in
the future.