This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 151656 - can't create named.conf and restart named from dhclient-enter-hookds
can't create named.conf and restart named from dhclient-enter-hookds
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-21 09:54 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-18 15:09:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
My dhclient-enter-hooks, for reference (445 bytes, text/plain)
2005-03-21 09:55 EST, Alexandre Oliva
no flags Details
Patch that enables dhclient-script to modify named configuration and zone files (515 bytes, patch)
2005-04-06 16:47 EDT, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2005-03-21 09:54:38 EST
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
Comment 1 Alexandre Oliva 2005-03-21 09:55:55 EST
Created attachment 112180 [details]
My dhclient-enter-hooks, for reference
Comment 2 Alexandre Oliva 2005-04-06 16:47:38 EDT
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?
Comment 3 Daniel Walsh 2005-04-07 10:26:44 EDT
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
Comment 4 Alexandre Oliva 2005-04-08 12:37:35 EDT
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.
Comment 5 Alexandre Oliva 2005-09-02 12:25:14 EDT
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)
Comment 6 Jason Vas Dias 2005-09-06 13:16:50 EDT
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
  
Comment 7 Jason Vas Dias 2005-09-06 13:21:31 EDT
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 

 
Comment 8 Jason Vas Dias 2005-09-06 13:27:04 EDT
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.
 
Comment 9 Daniel Walsh 2005-09-19 11:27:59 EDT
Jason can you write up policy to allow this?

Dan
Comment 10 Daniel Walsh 2005-11-03 17:32:55 EST
Is this fixed with current policy?
Comment 11 Alexandre Oliva 2005-11-30 13:37:07 EST
No, today's (well, yesterday's) rawhide still fails in this regard.
Comment 13 Russell Coker 2006-03-20 05:30:30 EST
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. 
Comment 16 Daniel Walsh 2006-09-18 15:09:27 EDT
This should be handled with loadable policy modules.

Note You need to log in before you can comment on or make changes to this bug.