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