Re: (should be) simple bind problem

[Glenn English <ghe@slsware.net>]

Bob Proulx sent me a number of suggestions, and I tested them. Then I inadvertently replied to him instead of the list.

Sorry, Bob, and thanks for the ideas.


On May 21, 2015, at 3:40 PM, Bob Proulx <bob@proulx.com> wrote:

> The first reason that comes to mind for permission denied is that it
> doesn't have permission.  Because the permission is allowed for user
> and group bind then it follows that the named must be running as a
> different user rather than the bind user.  Therefore the "-u bind"
> option must have been removed.
> 
> $ grep OPTIONS /etc/default/bind9
> OPTIONS="-u bind"

root@srv:~/init.d# egrep -i options /etc/default/bind9
# startup options for the server
OPTIONS="-u bind"

Nope.

> $ ps -ef | grep named
> bind      2257     1  0 May20 ?        00:00:27 /usr/sbin/named -u bind
> ^^^^

root@srv:~# ps -ef | grep named
bind      2098     1  0 May10 ?        00:00:36 /usr/sbin/named -u bind
root     10498     1  0 May10 ?        00:00:50 /usr/sbin/named -c /etc/bind/named.conf

> $ id bind
> uid=107(bind) gid=115(bind) groups=115(bind)

root@srv:~# id bind
uid=104(bind) gid=107(bind) groups=107(bind)

> Has the "-u bind" option been removed and the daemon is therefore
> running as a different user id?

After doing your tests, I really don't think so. But I don't know if ps' line

root     10498     1  0 May10 ?        00:00:50 /usr/sbin/named -c /etc/bind/named.conf

means anything. Looks like it might be about one of today's many restarts.

> If it isn't that then I would suspect selinux has become enabled but
> not fully configured.

I'm game. How do I find out/configure it?

root@srv:~# ps aux | egrep -i selinux
root     13013  0.0  0.0   7828   900 pts/0    S+   15:48   0:00 egrep -i selinux

If it's running, it doesn't have a pid. I don't really know what SELinux is. I've heard it's a collection of patches to the kernel, but that's all I know.

I grepped the /etc/default files for selinux. Nothing.

I grepped the /etc/init.d startup files. I found 'selinux-enabled' in the checkroot.sh file (if selinux-enabled ...). selinux-enabled is a small function in /lib/lsb/init-functions.sh:

selinux_enabled () {
       which selinuxenabled >/dev/null 2>&1 && selinuxenabled
}

'which selinuxenabled' says there's no such file here. So does 'root@srv:/boot# find / -iname "*selinuxenabled*""

I grepped the kernel config file in /boot:

root@srv:/boot# egrep -i selinux config-3.2.0-4-amd64 
CONFIG_SECURITY_SELINUX=y
# CONFIG_SECURITY_SELINUX_BOOTPARAM is not set
# CONFIG_SECURITY_SELINUX_DISABLE is not set
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set

I don't know enough about the kernel to know what those lines mean. Something SELinux seems to be included in the compile, but I haven't been able to find much of a trace of it. (The NSA's good at keeping secrets :-)

You did come up with some new and exciting things that might be bent, but they seem to be OK. And as best I can tell, there's just a hint of SELinux on this machine. 

This is happening on Dell, Supermicro, and RaspberryPi boxes, all running Wheezy with default, and updated, kernels, FWIW. The lone Lenny server doesn't seem to have troubles.

-- 
Glenn English