fedora core 9 bind problem

[Mark Andrews]

> On Fri, Jun 27, 2008 at 08:51:28AM +1000, Mark Andrews wrote:
> > 
> > > On Thu, Jun 26, 2008 at 10:19:25AM +1000, Mark Andrews wrote:
> > > > 
> > > > 	Named has *alway* required a writeable working directory.
> > > > 	This was explicitly pointed out in earlier versions of
> > > > 	manuals, etc.  The working directory is the default write
> > > > 	location for lots of files, in addition it is the default
> > > > 	on most OS's for core dumps.  Failure to provide this will
> > > > 	may cause some operations to fail.  It may also make it
> > > > 	more difficult to diagnose fatal problems which cause named
> > > > 	to exit.
> > > 
> > > Hm, could you point me why exactly working directory is required to be
> > > writable? We have writable subdirectories in working directory for
> > > secondary zones, DDNS zones, runtime information but many of files
> > > don't have to be writable - like zone files (non DDNS zones), keys
> > > etc. It improves security and doesn't affect named.
> > 
> > Please prove your assertion that a non-writable working directory
> > improves security.  Remember the working directory does not need
> > to be "/var/named". "/var/named/working", which is empty, will do
> > just fine.
> 
> Yes, I know that working directory will be empty but as far as I know
> zones configuration files has to be relative to working directory - so
> you have to write "../" in each zone configuration statement which is,
> of course, annoying. Please correct me if some nice solution exists.

	No.  Absolute works just as well as relative.  Named-checkconf
	and named-checkzone have a -t flag to match chroots performed
	by named.
 
> We keep working directory non-writable because admins simply write
> "file "zone_file";" to named.conf and zone is located in working
> directory. BIND could have security hole which might allow remote code
> execution so master zones will be corrupted - which will be pretty
> bad. Non writable directory prevents such attacks.

	And static master files are in the process of going away.
	More and more operations on the DNS are being done via
	UPDATE.  IPv6 and DNSSEC both encourage this.  Manipulating
	the zone by hand is happening less and less.
 
> From my point of view the best will be add option to named.conf and
> separate working directory and zones directory. Then all files which
> is supposed to be writable will be in working directory (like logs,
> statistics files, core files etc) and all others will be in
> non-writable directory.

	You already have that ability.

	If you are thinking about prepending a path to all relative
	file names that could theoretically be done.  It would
	require changes to not only named.  Note it is not always
	easy to determine if a file is relative or not.
 
> > > Only core files
> > > might be problem (it was discussed some time ago) but this is not
> > > common situation and admin can explicitly make working directory
> > > writable.
> > 
> > Which does not help with non-(easily)-reproducable conditions.  The
> > point in having the directory writable is that you catch the state
> > the server is in when you have a problem.
> > 
> > > > 	If the defaults presented by the OS don't meet the applications
> > > > 	needs then the defaults are wrong and should be corrected.
> > > > 	"defaults" here covers both the file system and the contents
> > > > 	of named.conf.
> > > > 
> > > > 	Mark
> > > 
> > > I'm ready to make working directory writable but I don't see any
> > > benefit now. Could you point me in which situations named could have
> > > problems?
> > 
> > Failure to write a core is a problem for anyone that wants support.
> > Named, deliberately, attempts to write core files.
> 
> You are absolutely right.
> 
> > 
> > Mark
> > 
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> 
> Adam
> 
> -- 
> Adam Tkac, Red Hat, Inc.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org