BIND less restrictive modes and policy

[Adam Tkac]

On Tue, Jan 22, 2008 at 11:30:05AM -0500, Chuck Anderson wrote:
> 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.

It is very hard to pass any new option or feature to main source.
Upstream is very very conservative. (as expected from server
developers...)

> > 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 
^^^ not needed ^^^

> chmod 775 /var/named
> setenforce 0
> service named restart
^^^ should be sufficient ^^^

> 
> 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...

Ok, so it seems that potential option to initscript which will
temporary modify /var/named perms and SELinux (for example we will
have some boolean for this) for gain such ability looks like the best
(despite I don't like it much :) )

Adam

-- 
Adam Tkac, Red Hat, Inc.