Re: BIND 9.14.0: unable to set effective uid to 0: Operation not permitted

2019-04-02 Thread Anand Buddhdev 
On 28/03/2019 14:40, Gasoo wrote:

Hi Stephan,

> Mar 25 16:41:56 dnsserver named[1348]: unable to set effective uid to 0:
> Operation not permitted

[snip]

> Why does named want to set the uid of itself back to 0?
> Has anyone seen this as well?

I'm not sure why it's doing that, but I think I know the reason for this
error message. The release notes of 9.14.0 say that on Linux, BIND uses
libcap to set certain privileges. However, if the /usr/sbin/named binary
is not marked as being able to use privileges, then it won't be able to
set certain privileges.

There are 2 possible options:

1. The simple one is to configure BIND with the "--disable-linux-caps"
option. The notes say that this comes at the cost of some security, but
it's not clear what the risks are.

2. In your SPEC file, you could mark the /usr/sbin/named binary
specially, so that it can use linux capabilities. For example, in the
%files section, you'd do something like:

%caps(cap_net_raw=ep) /path/to/named

But I still don't actually know what capabilities need to be set. The
above is just an example. Perhaps one of the BIND developers can shed
some light here.

Later when I have some time, I'm going to try and do some process
tracing to figure it out as well.

Regards,
Anand Buddhdev
RIPE NCC
___
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: BIND 9.14.0: unable to set effective uid to 0: Operation not permitted

2019-04-02 Thread Tony Finch 
Anand Buddhdev  wrote:
>
> I'm not sure why it's doing that, but I think I know the reason for this
> error message. The release notes of 9.14.0 say that on Linux, BIND uses
> libcap to set certain privileges. However, if the /usr/sbin/named binary
> is not marked as being able to use privileges, then it won't be able to
> set certain privileges.

I have not noticed these errors on my toy server. I had a look at the code
and I thought Stephan's explanation was correct. My guess is that he is
starting named without root privileges, so it is unable to switch back and
forth between users when it is starting up. It switches users so files
are created with the correct privileges, and as Stephan said, that is when
the warnings are emitted. It might be a combination of starting as an
unprivileged user and also providing the -u command line option.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
responsible stewardship of the earth and its resources
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

2019-04-02 Thread Sam Wilson 

On 2019-03-17 20:37:56 +, Alan Clegg said:


On 3/17/19 2:51 PM, Alan Clegg wrote:

On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:

Hello all,

I am using "BIND 9.13.7 (Development Release) " on arch linux. Up
to few days ago everything was fine using "certbot renew". I had
"allow-update" in nameds' global section, everything worked well. Updating to
the above version threw a config error that "allow-update" has no global scope
and is to be used in every single zone definition.


And you may have found a bug.  I'm checking internally at this time.


So, after a discussion with one of the BIND engineers this afternoon,
this turned out to be quite an interesting and deep-rooted issue.

During a cleanup of other code (specifically named-checkconf), code was
changed that enforced what was believed to have been the default
previously: specifically, allow-update was only allowed in zone stanzas.


Can I ask who believed it was previously the default?  I hope I'm not 
misreading the first dozen or so lines of this page (which seems to be 
reflected in previous editions of the ARM).


 



Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

2019-04-02 Thread Alan Clegg 
On 4/2/19 6:00 PM, Sam Wilson wrote:

>> During a cleanup of other code (specifically named-checkconf), code was
>> changed that enforced what was believed to have been the default
>> previously: specifically, allow-update was only allowed in zone stanzas.
> 
> Can I ask who believed it was previously the default?  I hope I'm not
> misreading the first dozen or so lines of this page (which seems to be
> reflected in previous editions of the ARM).
> 
> 

The answer to your question is:  "someone at ISC".

However, can you post exactly what you mean by "this page" and what
default we are talking about?  Based on the history of this e-mail
thread, I think that we are talking about "allow-update" being available
at the global view (up until 9.13.3) and it not being allowed there (the
rest of the 9.13 branch up until 9.14.0)

In the options section of the ARM I see:

allow-update
Specifies which hosts are allowed to submit Dynamic DNS updates for
master zones. The default is to deny updates from all hosts. Note that
allowing updates based on the requestor's IP address is insecure; see
the section called “Dynamic Update Security” for details.

in 9.12
(https://ftp.isc.org/isc/bind9/cur/9.12/doc/arm/Bv9ARM.ch05.html#options_grammar)
and:

allow-update
When set in the zone statement for a master zone, specifies which hosts
are allowed to submit Dynamic DNS updates to that zone. The default is
to deny updates from all hosts. This can only be set at the zone level,
not in options or view.

in 9.13 and 9.14.  The text here (as referred to in your link) is the
updated text that was changed at the same time that the code change was
made, thus matching what was released in 9.14.

AlanC
___
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: BIND 9.14.0: unable to set effective uid to 0: Operation not permitted

2019-04-02 Thread Anand Buddhdev 
On 02/04/2019 17:12, Tony Finch wrote:

Hi Tony,

> I have not noticed these errors on my toy server. I had a look at the code
> and I thought Stephan's explanation was correct. My guess is that he is
> starting named without root privileges, so it is unable to switch back and
> forth between users when it is starting up. It switches users so files
> are created with the correct privileges, and as Stephan said, that is when
> the warnings are emitted. It might be a combination of starting as an
> unprivileged user and also providing the -u command line option.

On my CentOS 7 test server, I start BIND 9.14.0 as root, like this:

named -f -u named

or

named -g -u named

It still emits those warnings.

Regards,
Anand
___
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: BIND 9.14.0: unable to set effective uid to 0: Operation not permitted

2019-04-02 Thread Gasoo 

Hello Anand / Tony

On 02/04/2019 20.25, Anand Buddhdev wrote:

On 02/04/2019 17:12, Tony Finch wrote:

Hi Tony,


I have not noticed these errors on my toy server. I had a look at the code
and I thought Stephan's explanation was correct. My guess is that he is
starting named without root privileges, so it is unable to switch back and
forth between users when it is starting up. It switches users so files
are created with the correct privileges, and as Stephan said, that is when
the warnings are emitted. It might be a combination of starting as an
unprivileged user and also providing the -u command line option.

On my CentOS 7 test server, I start BIND 9.14.0 as root, like this:

named -f -u named

or

named -g -u named

It still emits those warnings.


I also tried to start it manually as root on both, RHEL6 and 7:

named -u named -c /etc/named/named.conf -4 -t /var/named/chroot -g

The error message is also displayed twice on both systems.


I removed Linux capabilities with "--disable-linux-caps" and 
unsurprisingly, the error messages are not displayed anymore.
However, there are some drawbacks regarding security (According to the 
release notes) and I don't see any other reason to disable it.


Thank you for pointing out the caps setting in the SPEC file, I haven't 
thought about that.
However, I couldn't find anything about which Linux capabilities 
must/should be set in the SPEC file.



Kind Regards
Stephan
___
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