problem using setuid ("-u" option) with BIND 9.10.3 on RedHat when listening on tun/tap interface

Niall O'Reilly niall.oreilly at ucd.ie
Sun Sep 27 19:25:08 UTC 2015


On Sun, 27 Sep 2015 16:59:14 +0100,
Gordon Lang wrote:
> 
> Here is the file info:
> 
> glang at nstv1:/export/local/ISC> ls -ld bind-9.10.3/sbin
> bind-9.10.3/sbin/named
> drwxrwsr-x. 2 incadmin network 4096 Sep 26 10:39 bind-9.10.3/sbin
> -rwsr-xr-x. 2 root network 10095219 Sep 26 09:16
> bind-9.10.3/sbin/named
> glang at nstv1:/export/local/ISC>
> 
> If I run "named" as user 'glang' without the "-u" option, it works
> fine -- "named" runs as root (due to the suid file bit) and it listens
> on port 53 of the configured ip addresses.

  Real user is unprivileged, but effective user is, so it all works.

> If I run "named" as user 'glang' with the "-u incadmin" option, it
> does not work fine -- it runs with the change of process owner to
> 'incadmin', but it does not listen on any ip addresses.

  Real user is unprivileged. Effective user is briefly privileged,
  and later unprivileged.  In the section of the ARM which contains
  copies of the man pages, I see the following description of the
  -u option.

    -u user
    
      Setuid to user after completing privileged operations, such as
      creating sockets that listen on privileged ports.

      NOTE
      On Linux, named uses the kernel’s capability mechanism to drop
      all root privileges except the ability to bind(2) to a
      privileged port and set process resource limits. Unfortunately,
      this means that the -u option only works when named is run on
      kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since
      previous kernels did not allow privileges to be retained after
      setuid(2).  

  I don't doubt that you're running a new enough kernel.  However, I
  guess that, since the real user didn't have the privileges in
  question, the final effective user can't retain them.  Without
  checking kernel and/or named code, I'm afraid I can't do better then
  guess.

> If I run "named" as user 'root' with the "-u incadmin" option, it
> works fine -- it listens on the configured ip's and it changes the
> owner of the process to 'incadmin'.

  This is the "traditional" way to run a reduced-privilege instance of
  named.  I've used it, and I believe it's widely used.  Are you sure
  it's not adequately secure for your needs?

  Best regards,
  Niall O'Reilly
  


More information about the bind-users mailing list