BIND less restrictive modes and policy

[Chuck Anderson]

On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote:
> > I think we should investigate whether using 'directory 
> > "/var/named/data";' like I mentioned in my other email works first.  
> > How would people feel about needing full or ../ relative paths in zone 
> > "file" statements?
> 
> This doesn't sound well for me. This will be very annoying.

IMO, "annoying" is trumped by "more secure".  SELinux is annoying too, 
but we still use it.

I have verified that relative paths work, as well as symlinks from the 
data/ dir (not that I recommend doing it this way):

#ls -l /var/named/data
total 4
lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/

I think we need a new feature in BIND...one where the CWD can stay at 
/var/named/data regardless of the "directory" option so that zone file 
paths don't have to be changed--perhaps a new option.

> I don't think so. As I wrote in
> https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> to produce core file after setuid when /var/named directory is
> writable by named user. This is main reason why I want this directory
> writable. It means that you will have always core file when named
> gets sigsegv (no additional setup is needed, only writable
> /var/named). This change means lower security on the one hand but on
> the other hand we will always get core file.

Ok, I'll try this.  But I don't think we should change the default 
setup just to be able to generate coredumps at the expense of 
security, especially if we are still going to require SELinux to be 
put into permissive mode to make it actually work.  We should just 
document the changes one needs to make to generate coredumps since we 
already require some changes anyway, i.e.:

/etc/sysconfig/named:
DAEMON_COREFILE_LIMIT=unlimited

sysctl -w fs.suid_dumpable=1
chmod 755 /usr/sbin/named 
chmod 775 /var/named
setenforce 0
service named restart

(which of these aren't required?)

If we are going to make changes to allow coredumps by default, then 
SELinux policy should be adjusted to allow this as well because 
running your system in permissive mode for long periods of time makes 
it a royal pain to switch back--I had to boot into single user mode 
with selinux=0 and run "fixfiles restore" manually since rc.sysinit 
couldn't do it automatically (see 
https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.html 
for the problems I had).

I just don't think it is a good idea to implement this by making 
/var/named writeable, undoing the extra layer of security we have for 
master zone files now.  We should find some other way to mitigate 
this.  It's not like coredumps are frequent, and daemons aren't 
allowed to coredump with our default config anyway...