BIND less restrictive modes and policy
Adam Tkac
atkac at redhat.com
Tue Jan 22 16:50:53 UTC 2008
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.
More information about the fedora-devel-list
mailing list