On Mon, 22 Feb 2016 14:33:03 -0700 Glenn English <g...@srv.slsware.net> wrote:
> > > On Feb 22, 2016, at 1:59 PM, Reco <recovery...@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
