Re: BIND problem
On Mon, 22 Feb 2016 14:33:03 -0700
Glenn English <ghe@srv.slsware.net> wrote:
>
> > On Feb 22, 2016, at 1:59 PM, Reco <recoverym4n@gmail.com> wrote:
> >
> > No, that's not how you check it. Every Debian system has those records.
> > I meant something like 'ls -alZ /'.
>
> drwxr-xr-x 25 root root ? 4096 Jun 6 2014 .
> drwxr-xr-x 25 root root ? 4096 Jun 6 2014 ..
> drwxr-xr-x 2 root root ? 4096 Feb 19 10:26 bin
> drwxr-xr-x 3 root root ? 4096 Jan 7 21:40 boot
> drwxr-xr-x 14 root root ? 3380 Feb 22 02:34 dev
> drwxr-xr-x 127 root root ? 12288 Feb 22 14:12 etc
> drwxr-xr-x 3 root root ? 4096 Aug 31 00:42 home
> lrwxrwxrwx 1 root root ? 30 Oct 11 2013 initrd.img -> /boot/initrd.img-3.2.0-4-amd64
> drwxr-xr-x 15 root root ? 4096 Mar 17 2014 lib
> drwxr-xr-x 2 root root ? 4096 Feb 17 07:36 lib64
> drwx------ 2 root root ? 16384 Oct 11 2013 lost+found
> drwxr-xr-x 3 root root ? 4096 Oct 11 2013 media
> drwxr-xr-x 2 root root ? 4096 Jun 2 2013 mnt
> drwxr-xr-x 2 root root ? 4096 Oct 11 2013 opt
> dr-xr-xr-x 149 root root ? 0 Feb 22 02:33 proc
> drwxr-xr-x 3 root root ? 4096 Jun 6 2014 project
> drwx------ 23 root root ? 4096 Feb 21 20:24 root
> drwxr-xr-x 22 root root ? 960 Feb 22 14:12 run
> drwxr-xr-x 2 root root ? 4096 Feb 22 14:12 sbin
> drwxr-xr-x 2 root root ? 4096 Jun 10 2012 selinux
> drwxr-xr-x 3 root root ? 4096 Oct 11 2013 srv
> drwxr-xr-x 13 root root ? 0 Feb 22 02:34 sys
> drwxrwxrwx 4 nobody nogroup ? 4096 Apr 2 2014 tftpboot
> drwxrwxrwt 7 root root ? 4096 Feb 22 14:17 tmp
> drwxr-xr-x 11 root root ? 4096 Oct 11 2013 usr
> drwxr-xr-x 14 root root ? 4096 Feb 8 2014 var
> lrwxrwxrwx 1 root root ? 26 Oct 11 2013 vmlinuz -> boot/vmlinuz-3.2.0-4-amd64
So, the result has question marks instead of SELinux labels. This rules
out SELinux completely. Audit log would include SELinux violations
anyway, but still - simplest methods are the best :)
> > First, what does contents of /etc/default/bind9 look like?
>
> # run resolvconf?
> RESOLVCONF=yes
>
> # startup options for the server
> ### OPTIONS="-u bind"
> OPTIONS=" -4 -u bind"
And again, your usual run-of-the-mill Debian bind configuration file,
nothing to see here.
> > Second, can you install auditd please
>
> Selecting previously unselected package auditd.
> (Reading database ... 72472 files and directories currently installed.)
> Unpacking auditd (from .../auditd_1%3a1.7.18-1.1_amd64.deb) ...
> Processing triggers for man-db ...
> Setting up auditd (1:1.7.18-1.1) ...
>
> > and run
> > 'auditctl -w /var/cache/bind/slaves/ -p wa' afterward?
> > A contents of /var/log/audit/audit.log
>
> type=DAEMON_START msg=audit(1456174952.726:9009): auditd start, ver=1.7.18 format=raw kernel=3.2.0-4-amd64 auid=4294967295 pid=18137 res=success
> type=CONFIG_CHANGE msg=audit(1456174952.825:2): audit_backlog_limit=320 old=64 auid=4294967295 ses=4294967295 res=1
> type=LOGIN msg=audit(1456174953.225:3): login pid=18158 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=1
> type=LOGIN msg=audit(1456174953.301:4): login pid=18183 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=2
> type=LOGIN msg=audit(1456174981.336:5): login pid=18250 uid=0 old auid=4294967295 new auid=1 old ses=4294967295 new ses=3
> type=CONFIG_CHANGE msg=audit(1456174992.612:6): auid=4294967295 ses=4294967295 op="add rule" key=(null) list=4 res=1
>
> > it would be also required for
> > bind to fail to dump a zone at least once.
>
> I hadn't read that part until after I ran auditctl. I think there'd been several failed dumps before then, so I looked at the logs in hopes of giving you proof, but auditctl kept saying "Error sending add rule data request (Rule exists)". So I uninstalled --purge'ed it (and deleted it's log) and reinstalled it and ran 'date ; auditctl -w /var/cache/bind/slaves/ -p wa'. That printed the date and nothing else. I ran auditctl again, by itself, and it repeated the error statement.
Sorry, I forgot to add. To clear out audit rules you need to issue
'auditctl -D'. To view existing ones you need to issue 'auditctl -l'.
Reinstalling the package would clear the rules along the way, of
course.
> The logs say there have been many dump failures, so I'm pretty sure auditctl was run after a failed dump. I can't prove it, though.
And that leaves us exactly one possible explanation for this.
/var has 755 permissions, and owner:group of root.
/var/cache/bind/slaves has 775 permission, and owner:group of bind.
Since bind user is unable to write to /var/cache/bind/slaves, and audit
is unable to catch failed writes there - that can only mean that bind
user is unable to chdir to either /var/cache or /var/cache/bind.
So, what permissions does /var/cache and /var/cache/bind have?
Reco
Reply to: