Since the dibbler client (which my host wanted me to use to grab ipv6 leases, ugh) has no selinux policy I have migrated to dhcpcd which does have a policy. However, it needs a little bit of love... avc denials: Nov 13 18:31:01 testbed kernel: [38204.120242] audit: type=1400 audit(1415925061.852:373): avc: denied { getattr } for pid=8237 comm="dhcpcd-run-hook" path="/etc/ntp.conf" dev="dm-4" ino=321495 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ntp_conf_t tclass=file permissive=1 Nov 13 18:31:01 testbed kernel: [38204.125848] audit: type=1400 audit(1415925061.857:374): avc: denied { read } for pid=8253 comm="sed" name="ntp.conf" dev="dm-4" ino=321495 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ntp_conf_t tclass=file permissive=1 Nov 13 18:31:01 testbed kernel: [38204.125870] audit: type=1400 audit(1415925061.857:375): avc: denied { open } for pid=8253 comm="sed" path="/etc/ntp.conf" dev="dm-4" ino=321495 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ntp_conf_t tclass=file permissive=1 This issue is nominally resolved through this sysnetwork.te entry: # Allow read/write to /etc/resolv.conf and /etc/ntp.conf. Note that any files # in /etc created by dhcpcd will be labelled net_conf_t. sysnet_manage_config(dhcpc_t) files_etc_filetrans(dhcpc_t, net_conf_t, file) Working through the ntp.fc, I find that ntp.conf gets pushed under the aegis of ntp_conf_t (which makes sense). I see two solutions: 1) Make a domain transition specifically for accessing ntp_conf_t, which strikes me as unnecessary. 2) Relabel ntp.conf to net_conf_t Option #2 seems the most reasonable, though more expansive in change. I personally do not see any issue with this fix. This change is pretty easy: diff --git a/policy/modules/contrib/ntp.fc b/policy/modules/contrib/ntp.fc index 6105583..c3b4744 100644 --- a/policy/modules/contrib/ntp.fc +++ b/policy/modules/contrib/ntp.fc @@ -2,8 +2,8 @@ /etc/cron\.(daily|weekly)/ntp-simple -- gen_context(system_u:object_r:ntpd_exec_t,s0) /etc/cron\.(daily|weekly)/ntp-server -- gen_context(system_u:object_r:ntpd_exec_t,s0) -/etc/ntp\.conf -- gen_context(system_u:object_r:ntp_conf_t,s0) -/etc/ntpd.*\.conf.* -- gen_context(system_u:object_r:ntp_conf_t,s0) +/etc/ntp\.conf -- gen_context(system_u:object_r:net_conf_t,s0) +/etc/ntpd.*\.conf.* -- gen_context(system_u:object_r:net_conf_t,s0) /etc/ntp/crypto(/.*)? gen_context(system_u:object_r:ntpd_key_t,s0) /etc/ntp/data(/.*)? gen_context(system_u:object_r:ntp_drift_t,s0) /etc/ntp/keys -- gen_context(system_u:object_r:ntpd_key_t,s0) The ntp policy appears to have access to net_conf_t already as I have not seen any further policy violatins from ntp after the change & relabel. Reproducible: Always
Depending on #529146, as issues I'm squishing are present with that fix in place.
Heh. dhcpcd can grab IPv6 leases just as well :)
From a first looks, if there is an ntp_conf_t which is used for ntp.conf, then we should stick to that. Using a named file transition with dhcpcd for ntp.conf is not a problem at all.
Created attachment 389374 [details, diff] ntp interface / socket patch
Roy: I am using dhcpcd :p Sven: In that case, I've gone ahead and given ntp an interface for domains to read (only read!) ntp_conf_t and then I assigned the permission to dhcpcd_t. An extra thing showed up after. Turns out that dhcpcd likes to listen for udev events on a uevent socket which it doesn't have permissions to do, so I've added that in as well. I, obviously, have dhcpcd built with udev. EG: Nov 15 05:40:11 testbed kernel: [164853.721650] audit: type=1400 audit(1416051611.114:4148): avc: denied { create } for pid=1527 comm="dhcpcd" ipaddr=REDACTED scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t tclass=netlink_kobject_uevent_socket permissive=1 Fixes attached.
So dhcpcd calls its hooks script (dhcpcd-run-hook) which will do whatever the system administrator wants in order to facilitate / automate processes and tasks when a renewal of IP address occurs. Right now, the hooks run in the dhcpc_t domain itself. I'm wondering if it wouldn't make sense to separate this from the dhcpc_t domain (like through a dhcpc_hooks_t domain). I'll do some tests to validate this.
I think a nice way to handle such a case is the following: We define a dhcpc_script_t domain, which is transitioned to by dhcpc_t when executing the dhcpcd-run-hooks script (labelled as dhcpc_script_exec_t). The dhcpc_script_t domain has similar manage privileges as currently documented in the policy, namely net_conf_t and ntp_conf_t (yes, in the comments, it states that this was the intention - the execution sadly wasn't as good). Alongside this domain, an interface like sysnet_dhcpc_script_entry (similar to cron_system_entry) is made available so that additional scripts that administrators would like to execute can be used to transition easily. All the admin then has to do is: sysnet_dhcpc_script_entry(somedomain_t, somedomain_exec_t) and have his script be labeled as somedomain_exec_t. Reason for a separate domain: whatever is being run through the hooks is not under control of the application anymore. By keeping dhcpc_t close to the application, we can also ensure that the necessary privileges don't blow up. Reason for an _entry interface: this way we do not need to blow up the dhcpc_script_t privileges too much. We can put in some slack and support the common sets of configuration management approaches (based on experience) without the need to consider all possible use cases.
The change seems to work pretty well. It is currently in the "next" branch as I'll ask around on our mailinglist if others accept this change (as there is a risk that this will not be easy to upstream).
Ok, merged. Will be in r2.
r2 is in tree, ~arch
Just to touch on this now that I'm rebasing back to stock and using everything pushed in since november or so, I can say this works. No more complaints from dhcpcd.
stable
