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

[Niall O'Reilly]

On Sat, 26 Sep 2015 17:27:56 +0100,
Gordon Lang wrote:
> 
> CHANGE: I did not properly characterized the problem in my original
> post, so here is the real situation.
> 
> If the bash shell from which I launch "named" is owned by root, then
> "named" runs perfectly using the "-u" option, even listening on the
> tun/tap interfaces.
> But if I run "named" as a regular user, relying on the SUID file
> setting to elevate privileges, then named fails to listen on any
> addresses.
> I believe the differences I saw before related to tun/tap interfaces
> were due to testing on different RedHat platforms, but this revised
> problem statement describes what is happening on both platforms.
> 
> So the real problem is this: It seems I can use the SUID file bit to
> allow a regular user to launch named, OR I can use the "-u" option of
> "named" to lower the privileges after launch (requiring native root
> privileges to launch), but I can't use both at the same time.
> 
> Can anyone shed any light on this scenario?

  I'm missing some information which might help me understand the
  problem: the user and group to which your named belong.

  Best regards,
  Niall O'Reilly
  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Gordon Lang]

Here is the file info:

glang@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@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.

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.

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'.

--
Gordon A. Lang


On Sun, Sep 27, 2015 at 9:09 AM, Niall O'Reilly 
wrote:

> On Sat, 26 Sep 2015 17:27:56 +0100,
> Gordon Lang wrote:
> >
> > CHANGE: I did not properly characterized the problem in my original
> > post, so here is the real situation.
> >
> > If the bash shell from which I launch "named" is owned by root, then
> > "named" runs perfectly using the "-u" option, even listening on the
> > tun/tap interfaces.
> > But if I run "named" as a regular user, relying on the SUID file
> > setting to elevate privileges, then named fails to listen on any
> > addresses.
> > I believe the differences I saw before related to tun/tap interfaces
> > were due to testing on different RedHat platforms, but this revised
> > problem statement describes what is happening on both platforms.
> >
> > So the real problem is this: It seems I can use the SUID file bit to
> > allow a regular user to launch named, OR I can use the "-u" option of
> > "named" to lower the privileges after launch (requiring native root
> > privileges to launch), but I can't use both at the same time.
> >
> > Can anyone shed any light on this scenario?
>
>   I'm missing some information which might help me understand the
>   problem: the user and group to which your named belong.
>
>   Best regards,
>   Niall O'Reilly
>
>


-- 

--
Gordon A. Lang
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Rick Dicaire]

Unless something has changed, root is required to bind to ports below 1024
before privilege separation can begin.

On Sun, Sep 27, 2015 at 11:59 AM, Gordon Lang  wrote:

> Here is the file info:
>
> glang@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@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.
>
> 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.
>
> 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'.
>
> --
> Gordon A. Lang
>
>
> On Sun, Sep 27, 2015 at 9:09 AM, Niall O'Reilly 
> wrote:
>
>> On Sat, 26 Sep 2015 17:27:56 +0100,
>> Gordon Lang wrote:
>> >
>> > CHANGE: I did not properly characterized the problem in my original
>> > post, so here is the real situation.
>> >
>> > If the bash shell from which I launch "named" is owned by root, then
>> > "named" runs perfectly using the "-u" option, even listening on the
>> > tun/tap interfaces.
>> > But if I run "named" as a regular user, relying on the SUID file
>> > setting to elevate privileges, then named fails to listen on any
>> > addresses.
>> > I believe the differences I saw before related to tun/tap interfaces
>> > were due to testing on different RedHat platforms, but this revised
>> > problem statement describes what is happening on both platforms.
>> >
>> > So the real problem is this: It seems I can use the SUID file bit to
>> > allow a regular user to launch named, OR I can use the "-u" option of
>> > "named" to lower the privileges after launch (requiring native root
>> > privileges to launch), but I can't use both at the same time.
>> >
>> > Can anyone shed any light on this scenario?
>>
>>   I'm missing some information which might help me understand the
>>   problem: the user and group to which your named belong.
>>
>>   Best regards,
>>   Niall O'Reilly
>>
>>
>
>
> --
>
> --
> Gordon A. Lang
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Niall O'Reilly]

On Sun, 27 Sep 2015 16:59:14 +0100,
Gordon Lang wrote:
> 
> Here is the file info:
> 
> glang@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@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
  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 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"  wrote:

> On Sun, 27 Sep 2015 16:59:14 +0100,
> Gordon Lang wrote:
> >
> > Here is the file info:
> >
> > glang@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@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
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 2015-09-27 at 15:31 -0400, Gordon Lang wrote:

> > It works fine with BIND 9.9.3 but not 9.10.3 on the same server.

Since this is rhel6, I presume you are running with selinux:

cat /etc/selinux/config

grep named /var/log/audit/audit.log | audit2allow

How did you do the build of 9.10.3 on rhel6? Did you build rpms from a
.spec file, or just a raw autoconf (./configure;make;make install)
build?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlYIj6AACgkQL6j7milTFsHcnACfUk+MZP5OaFV3h9PJzXye4dam
neQAn1+NLhqFH7gPZanWaAAXeb2ZptJk
=zpxb
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Mark Andrews]

In message 
, 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"  wrote:
> 
> > On Sun, 27 Sep 2015 16:59:14 +0100,
> > Gordon Lang wrote:
> > >
> > > Here is the file info:
> > >
> > > glang@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@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
> 
> It works fine with BIND 9.9.3 but not 9.10.3 on the same ser=
> ver.
> On Sep 27, 2015 3:25 PM, "Niall O'Reill=
> y" niall.orei...@ucd.ie >> wrote: e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun,=
>  27 Sep 2015 16:59:14 +0100,
> Gordon Lang wrote:
> >
> > Here is the file info:
> >
> > glang@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@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.
> 
> =C2=A0 Real user is unprivileged, but effective user is, so it all works. r>
> 
> > If I run "named" as user 'glang' with the "-u i=
> ncadmin" 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.
> 
> =C2=A0 Real user is unprivileged. Effective user is briefly privileged,
> =C2=A0 and later unprivileged.=C2=A0 In the section of the ARM which contai=
> ns
> =C2=A0 copies of the man pages, I see the following description of the
> =C2=A0 -u option.
> 
> =C2=A0 =C2=A0 -u user
> 
> =C2=A0 =C2=A0 =C2=A0 Setuid to user after completing privileged operation