The kicker was probably this line:

Sep  6 15:44:40 ns3 audit: <audit-1400> { write } for  pid=15447 comm="named" 
name="named.secroots" dev="dm-0" ino=135707451 
scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 
tclass=file permissive=0

The SELinux context that BIND runs in on a red hat system doesn't have access 
to write to a file of etc_t. After moving the file to /var/named somewhere, a 
restorecon should have reset it to something like var_named_t or 
var_named_cache_t which it would have had access to write to.

>From the line, 'permissive=0' so it suggests a SELinux-enforcing environment.
Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Brent 
Swingle
Sent: Friday, 7 September 2018 12:05 PM
To: bind-users@lists.isc.org
Subject: Re: [BIND] RE: KSK Rollover

This matter has been resolved with input from Evan.  I was able to add a file 
path for secroots to the named.conf file and push the output file to a temp 
directory that was not permission restricted.

secroots-file "/tmp/named.secroots" ;


Ultimately when I ran "rndc secroots" it created the output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots


The data in the file seems to be as desired if I understand the KSK Rollover 
test correctly, I should see 20326 which pertains to the new key:

[root@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found




I did not fully try Carl's input below but I believe it would have worked as 
well.  I had performed a "chmod 770 /var/named" but I did not follow it up with 
the SELinux modification.  The last error I had was SELinux barking so I'd 
anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots




Thanks everyone for assisting with this matter.
_______________________________________________
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

Reply via email to