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

[Gordon Lang]

It works fine with BIND 9.9.3 but not 9.10.3 on the same server.
On Sep 27, 2015 3:25 PM, "Niall O'Reilly" <niall.oreilly at ucd.ie> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150927/1a523df8/attachment-0001.html>