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