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

Mark Andrews marka at isc.org
Mon Sep 28 01:03:14 UTC 2015


In message <CAC4BHT7G4Lje+Fi4Um539o-K_W7n7hBBpvD3zN4Z0Fw1RyLDZA at mail.gmail.com>
, Gordon Lang writes:
> 
> It works fine with BIND 9.9.3 but not 9.10.3 on the same server.

9.9.3 doesn't build threaded by default.
9.10.3 does build threaded by default.

Linux threads are a total mess as they are implemented as multiple
processes rather than actual threads of a single process.  This
means that syscalls that should apply to all threads don't and you
can't do things like change the uid of a program with multiple
threads active.

Additionally named isn't written as a suid executable.  It assumes
it is running as a ordinary user or as root (real, effective and
saved uid's are all zero) when starting.

It then temporarially changes uid several times, when running with
-u, to get the correct ownership and atomicity when creating files
and still have the right permissions when it needs them.

Mark

> 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=E2=80=99s capability mechanism to d=
> rop
> >       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).  =EF=BF=BC
> >
> >   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
> >
> >
> 
> --e89a8f83a3f94dc2e00520bf9f06
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">It works fine with BIND 9.9.3 but not 9.10.3 on the same ser=
> ver.</p>
> <div class=3D"gmail_quote">On Sep 27, 2015 3:25 PM, "Niall O'Reill=
> y" <<a href=3D"mailto:niall.oreilly at ucd.ie">niall.oreilly at ucd.ie</a=
> >> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" styl=
> e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun,=
>  27 Sep 2015 16:59:14 +0100,<br>
> Gordon Lang wrote:<br>
> ><br>
> > Here is the file info:<br>
> ><br>
> > glang at nstv1:/export/local/ISC> ls -ld bind-9.10.3/sbin<br>
> > bind-9.10.3/sbin/named<br>
> > drwxrwsr-x. 2 incadmin network 4096 Sep 26 10:39 bind-9.10.3/sbin<br>
> > -rwsr-xr-x. 2 root network 10095219 Sep 26 09:16<br>
> > bind-9.10.3/sbin/named<br>
> > glang at nstv1:/export/local/ISC><br>
> ><br>
> > If I run "named" as user 'glang' without the "-=
> u" option, it works<br>
> > fine -- "named" runs as root (due to the suid file bit) and =
> it listens<br>
> > on port 53 of the configured ip addresses.<br>
> <br>
> =C2=A0 Real user is unprivileged, but effective user is, so it all works.<b=
> r>
> <br>
> > If I run "named" as user 'glang' with the "-u i=
> ncadmin" option, it<br>
> > does not work fine -- it runs with the change of process owner to<br>
> > 'incadmin', but it does not listen on any ip addresses.<br>
> <br>
> =C2=A0 Real user is unprivileged. Effective user is briefly privileged,<br>
> =C2=A0 and later unprivileged.=C2=A0 In the section of the ARM which contai=
> ns<br>
> =C2=A0 copies of the man pages, I see the following description of the<br>
> =C2=A0 -u option.<br>
> <br>
> =C2=A0 =C2=A0 -u user<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 Setuid to user after completing privileged operations,=
>  such as<br>
> =C2=A0 =C2=A0 =C2=A0 creating sockets that listen on privileged ports.<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 NOTE<br>
> =C2=A0 =C2=A0 =C2=A0 On Linux, named uses the kernel=E2=80=99s capability m=
> echanism to drop<br>
> =C2=A0 =C2=A0 =C2=A0 all root privileges except the ability to bind(2) to a=
> <br>
> =C2=A0 =C2=A0 =C2=A0 privileged port and set process resource limits. Unfor=
> tunately,<br>
> =C2=A0 =C2=A0 =C2=A0 this means that the -u option only works when named is=
>  run on<br>
> =C2=A0 =C2=A0 =C2=A0 kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later=
> , since<br>
> =C2=A0 =C2=A0 =C2=A0 previous kernels did not allow privileges to be retain=
> ed after<br>
> =C2=A0 =C2=A0 =C2=A0 setuid(2).=C2=A0 =EF=BF=BC<br>
> <br>
> =C2=A0 I don't doubt that you're running a new enough kernel.=C2=A0=
>  However, I<br>
> =C2=A0 guess that, since the real user didn't have the privileges in<br=
> >
> =C2=A0 question, the final effective user can't retain them.=C2=A0 With=
> out<br>
> =C2=A0 checking kernel and/or named code, I'm afraid I can't do bet=
> ter then<br>
> =C2=A0 guess.<br>
> <br>
> > If I run "named" as user 'root' with the "-u in=
> cadmin" option, it<br>
> > works fine -- it listens on the configured ip's and it changes the=
> <br>
> > owner of the process to 'incadmin'.<br>
> <br>
> =C2=A0 This is the "traditional" way to run a reduced-privilege i=
> nstance of<br>
> =C2=A0 named.=C2=A0 I've used it, and I believe it's widely used.=
> =C2=A0 Are you sure<br>
> =C2=A0 it's not adequately secure for your needs?<br>
> <br>
> =C2=A0 Best regards,<br>
> =C2=A0 Niall O'Reilly<br>
> <br>
> </blockquote></div>
> 
> --e89a8f83a3f94dc2e00520bf9f06--
> 
> --===============0301327172722298146==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============0301327172722298146==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list