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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
