Hi all
Through one of the bugreports [1] we came across the situation that an
application (DHCP in this case) supports "hooks", as a sort of pre- or
post-processing executions, which are under the control of the
administrator.
This flexibility is wonderful of course, as it allows for automation of
additional tasks after an IP address is obtained. Of course, "additional
tasks" has other consequences, namely that those tasks might not be fully
specific to the DHCP operation itself.
Right now, these hooks run under the dhcpc_t domain, which is relatively
powerful (not extremely, but it is a system domain after all). I can imagine
from a security point-of-view we might not want to have the hooks (which
could be as broad as calling puppet, pusing information to a remote server
for things like dyndns handling, etc.) run in the dhcpc_t domain.
For this reason, I played around with the idea to separate the hook
execution in a different domain (called "dhcpc_script_t") which is able to
manage network configuration files (and NTP configuration, as this hook is
also by default provided and was the original source of the bug report).
This domain could be made relatively flexible in what it does, without
impacting dhcpc_t.
Next to the additional domain, I also introduced a
sysnet_dhcpc_script_entry() interface, which allows administrators to easily
add domains that can be transitioned to from the dhcpc_script_t domain -
similar to the cron_system_entry() interface for cron jobs. That way, if a
hook would require permissions that we do not want to grant to
dhcpc_script_t, we can just put those permissions in a separate domain and
allow the domain transition, without the need to update the sysnetwork.te
module itself.
I think this is a flexible, manageable and secure way to handle the
situation, but it might not be easy to upstream this directly, meaning that
we will need to keep supporting it in our repository for some time. I'm okay
with this, but I think it is best to report it here so others know about it.
The change is currently in the hardened-refpolicy repo, "next" branch.
Wkr,
Sven Vermeulen
[1] https://bugs.gentoo.org/show_bug.cgi?id=529204
Through one of the bugreports [1] we came across the situation that an
application (DHCP in this case) supports "hooks", as a sort of pre- or
post-processing executions, which are under the control of the
administrator.
This flexibility is wonderful of course, as it allows for automation of
additional tasks after an IP address is obtained. Of course, "additional
tasks" has other consequences, namely that those tasks might not be fully
specific to the DHCP operation itself.
Right now, these hooks run under the dhcpc_t domain, which is relatively
powerful (not extremely, but it is a system domain after all). I can imagine
from a security point-of-view we might not want to have the hooks (which
could be as broad as calling puppet, pusing information to a remote server
for things like dyndns handling, etc.) run in the dhcpc_t domain.
For this reason, I played around with the idea to separate the hook
execution in a different domain (called "dhcpc_script_t") which is able to
manage network configuration files (and NTP configuration, as this hook is
also by default provided and was the original source of the bug report).
This domain could be made relatively flexible in what it does, without
impacting dhcpc_t.
Next to the additional domain, I also introduced a
sysnet_dhcpc_script_entry() interface, which allows administrators to easily
add domains that can be transitioned to from the dhcpc_script_t domain -
similar to the cron_system_entry() interface for cron jobs. That way, if a
hook would require permissions that we do not want to grant to
dhcpc_script_t, we can just put those permissions in a separate domain and
allow the domain transition, without the need to update the sysnetwork.te
module itself.
I think this is a flexible, manageable and secure way to handle the
situation, but it might not be easy to upstream this directly, meaning that
we will need to keep supporting it in our repository for some time. I'm okay
with this, but I think it is best to report it here so others know about it.
The change is currently in the hardened-refpolicy repo, "next" branch.
Wkr,
Sven Vermeulen
[1] https://bugs.gentoo.org/show_bug.cgi?id=529204