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