I run named on all of my boxes, that are set up to use the dhcp-provided DNS server for most but not all domains. To this extent, I had a named.conf.in file with a template containing @DNS@ markers that /etc/dhclient-enter-hooks replaces, by means of a sed script, with the dns server discovered with dhcp, creating named.conf and then condrestarting named. The problem I have is that I can't figure out how to set up the contexts for dhclient-enter-hooks, named.conf.in and named.conf, such that: - dhclient-enter-hooks can read named.conf.in and create/write to named.conf - dhclient-enter-hooks can restart named - named can read named.conf I know how I could extend the existing policy sources to accomplish this, but what I'm aiming for is something built into the default targeted policy. Is the policy designed to not support this behavior, or would extensions to this effect be acceptable? Version-Release number of selected component (if applicable): selinux-policy-targeted-1.23.3-2
Created attachment 112180 [details] My dhclient-enter-hooks, for reference
Created attachment 112780 [details] Patch that enables dhclient-script to modify named configuration and zone files Since dhclient-scripts can already create resolv.conf and ntpd.conf, I suppose there's not much harm if it can change named.conf as well, is there?
I think this would be a one off. I don't think we want the dhcp client able to write to named. So if someone compromized you dhcp client they could compromize your named. So I think you would want to write custom policy to satisfy your needs. I would put your custom policy in domains/misc rather then in the actual dhcpc.te file, since rpm could replace dhcpc.te in the future. Dan
I don't think the need to do this is as rare as you make it sound. Even NetworkManager modifies named.conf, because it depends on a caching name server, instead of just listing possibly multiple upstream name servers in resolv.conf. Sure enough, it does change named.conf in different ways, but the fact that it needs this is a proof that the need is there. Now, just because I don't use NetworkManager and would rather do the configuration at the IMHO right spot, I have to tweak the selinux rules? How about we control these permissions with a boolean instead? I certainly wouldn't mind having it default to off, but I'd really like to be able to enable it without having to recompile the policy.
FWIW, here are the custom rules I needed to introduce to get this problem solved for me. Could they pretty please be added to the default policy, controlled by a boolean, even if it's off by default? allow dhcpc_t named_conf_t:dir search; allow dhcpc_t named_conf_t:file { getattr read write }; allow dhcpc_t named_zone_t:dir search; domain_auto_trans(dhcpc_t, named_exec_t, named_t)
I think it is reasonable to allow scripts run from the dhclient-*-hooks scripts. NOTE with dhcp-3.0.3-4+ (Rawhide) and dhcp-3.0.2-20+ (FC-4) there are now dhclient-up-hooks (run after 'ifconfig * up' done) and dhclient-down-hooks (run before 'ifconfig * down' done). NOTE also that with bind-9.3.1-10+ (Rawhide), you can add or remove forwarder nameservers dynamically with D-BUS, by giving the '-D' "Enable D-BUS" option to named at startup (see /usr/share/doc/bind*/README.DBUS on a rawhide system). So, you could put in /etc/dhclient-up-hooks, for example : for $dn in $new_domain_name ; do for $svr in $new_domain_servers ; do /sbin/dbus-send --system --type=method_call \ --print_reply --reply_timeout=20000 \ --dest=com.redhat.named \ /com/redhat/named \ com.redhat.named.SetForwarders \ string:"$dn" \ string:"$svr" done IFS='.' octs=($dname) unset IFS dname='' for oct in ${octs[@]}; do dname="$oct.$dname"; done dname="${dname}in-addr.arpa."e done
ARGH! Pressed return too soon. As I was saying, in dhclient-up-hooks: for $dn in $new_domain_name ; do for $svr in $new_domain_servers ; do /sbin/dbus-send --system --type=method_call \ --print_reply --reply_timeout=20000 \ --dest=com.redhat.named \ /com/redhat/named \ com.redhat.named.SetForwarders \ string:"$dn" \ string:"$svr" done # set reverse IP forwarder: IFS='.' octs=($new_ip_address) unset IFS dname='' for oct in ${octs[0]} ${octs[1]} ${octs[2]}; do dname="$oct.$dname"; done dname="${dname}in-addr.arpa." /sbin/dbus-send --system --type=method_call \ --print_reply --reply_timeout=20000 \ --dest=com.redhat.named \ /com/redhat/named \ com.redhat.named.SetForwarders \ string:"$dname" \ string:"$svr"; done And in dhclient-down-hooks: for $dn in $old_domain_name ; do for $svr in $old_domain_servers ; do /sbin/dbus-send --system --type=method_call \ --print_reply --reply_timeout=20000 \ --dest=com.redhat.named \ /com/redhat/named \ com.redhat.named.SetForwarders \ string:"$dn" \ string:"$svr" done # set reverse IP forwarder: IFS='.' octs=($old_ip_address) unset IFS dname='' for oct in ${octs[0]} ${octs[1]} ${octs[2]}; do dname="$oct.$dname"; done dname="${dname}in-addr.arpa." /sbin/dbus-send --system --type=method_call \ --print_reply --reply_timeout=20000 \ --dest=com.redhat.named \ /com/redhat/named \ com.redhat.named.SetForwarders \ string:"$dname" \ string:"$svr"; done
oops, {old,new}_domain_servers should be {old,new}_domain_name_servers above. But you get the idea. NetworkManager will shortly be using this dynamic forwarder table management D-BUS mechanism. Use of "dhcdbd" to do an ifup / ifdown with named started with '-D' would cause named to automatically add / remove the new forwarders itself on receipt of dhcdbd interface up / down events. So yes, I agree that we should allow dhclient AND dhcpd to write named.conf with a boolean tunable that could default to off. dhcpd also has "execute" actions to take on certain leases being granted; this could be used to allow a new zone slave, for example.
Jason can you write up policy to allow this? Dan
Is this fixed with current policy?
No, today's (well, yesterday's) rawhide still fails in this regard.
I think this is too much of a special-case to consider for an FC4 update, so I'll change it to FC5. For FC5 with dbus am I correct in my impression that all we need is to have a boolean to determine whether named_t gets write access to named_conf_t? Naturally we don't want to unconditionally grant write access because most people who run DNS servers don't want the server to re-write it's own config files. We could put this in a FC5 update.
This should be handled with loadable policy modules.