In-Reply-To: Dmarc-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ED713552DC CC: "Tomas Hozza" X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org From: "Petr Menšík" X-Scanned-BY: MIMEDefang 2.79 on 10.5.11.13 Content-Language: en-US X-RT-Original-Encoding: utf-8 To: bind9-public@isc.org Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pemensik@redhat.com Subject: Re: [ISC-Bugs #46242] [PATCH] nta-directory support Content-Transfer-Encoding: 8bit content-type: text/plain; charset="utf-8" X-RT-Interface: Email Return-Path: X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-RT-Incoming-Encryption: Not encrypted X-Original-To: bind9-public@bugs.isc.org Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 30752D78B0A for ; Fri, 27 Oct 2017 15:47:38 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9925D3B2725 for ; Fri, 27 Oct 2017 15:47:35 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ED713552DC for ; Fri, 27 Oct 2017 15:47:34 +0000 (UTC) Received: from menpad.brq.redhat.com (unknown [10.40.205.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A5A1960602; Fri, 27 Oct 2017 15:47:33 +0000 (UTC) MIME-Version: 1.0 From pemensik@redhat.com Fri Oct 27 15:47:38 2017 Delivered-To: bind9-public@bugs.isc.org References: <6f010d00-2cc0-bcd9-cb68-88c501827274@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 27 Oct 2017 15:47:35 +0000 (UTC) Date: Fri, 27 Oct 2017 17:47:29 +0200 Message-ID: <0ac4dedc-3fa7-4d3b-b71b-189a766d3288@redhat.com> RT-Message-ID: Content-Length: 6288 Hi Ondřej, I admit changing directory for each type of file is not a great solution. More reasons below. Would you accept new option common for all zone-specific files (mkeys, nzf, nta)? I think already accepted new-zones-directory could be obsoleted in favor of common one. I spent some time thinking how can we change it to not break our existing installations or make them less secure. I could not find good way to solve without a radical change of bind home layout. We definitely want to avoid that. Dne 10.10.2017 v 17:01 Ondrej Sury via RT napsal(a): > On Tue Oct 10 14:29:23 2017, pemensik@redhat.com wrote: >> Hello, >> >> I mentioned already in ticket for new-zones-directory option we ship >> BIND with /var/named directory read-only to named user by default. In >> default installation named daemon can write into >> /var/named/{data,dynamic,slaves} but not /var/named. Read ticket #44853 >> for more detailed explanation. > > Hi Petr, > > there's a description here and in the #44853, but I haven't really found a technical reasoning why is this a good thing to do. > > What about instead of bikeshedding the configuration option you just set the working directory to be writeable. > > There are two possible approaches to this: > > a) just make /var/named writeable to bind user. The individual master zones shouldn't be writeable anyway (otherwise the security just wouldn't make sense anyway), so there would be not much difference to existing state Read-only /var/named has been in RHEL at least since 2006. We may reconsider how useful it really is today, because we already have cases that need exceptions. I think we missed the best moment to recommend our users to not use relative zone file paths to home directory, but choose other directory for master files. We might reconsider it now, but we would need something to keep backward compatibility. I think clear separation of zone files from automatically created files is a good idea. Especially those managed only manually. I checked how it is handled in Debian and OpenSUSE. Both moved from /var/named to /var/cache/bind or /var/lib/named, where write access is allowed. Debian's /var/cache/bind is great place for any secondary zones. After all it is a cache of them, nothing more. If cache is cleared, they will be fetched again automatically. It is not as great for auto managed dnssec zones in my opinion. Stick bit can be used to protect read-only files in writeable directory. Writeable subdirectories are preferred by us. We do not want users to change SELinux security contexts of selected files manually after changing unix permissions however. We want them to declare their intention by selecting selecting the directory for zone files. > > b) move working directory to something else /var/tmp/named (??), and top it up with a small patch to resolve relative directories to working_dir first and then to /var/named (hardcoded on RedHat). Any kind of hardcoded path would not work for us. Different complicated setups have to be supported. We want to be as close to upstream bind while not breaking our setup. I prefer no Red Hat specific options that would not be present in upstream. We have different directory layout, but want to have compatible binary. Relative zones should not be tried first from working_dir however. All this was done to improve security. If attacker finds a way to remotely change files from named (or as bind user), he must not be able to modify zones served to users. This way, he would just create his own zone copy in /var/lib/named with unauthorized content. On next reload, his data would be served. This is exactly what we want to prevent by SELinux extension. I admit I do not remember any CVE that would allow such thing. > > I think that adding more and more directives to scatter individual writeable directories across the filesystem just doesn't make much sense. I agree with that. Maybe single option common for more of them would be more useful? Obsoleting new-zone-directory option as well and providing default value unless managed-keys-directory was used. Groups of I think there 4 are types of files named handles: 1) Write only dumps of current status. secroots, recursing, dumpdb, statistics and memstatistics files. It would help us to have one common directory for all of those that could be changed by single option. They already have path option for each of them. /var/named/data is used for them on RHEL. Option export-directory "/var/named/data" would simplify our current setup. It is possible to override each such file for a view, so only nice to have feature to me. 2) Read and write databases, lets call them mananaged databases. Currently configurable per-view. managed-keys (mkeys), new-zone (nzf,nzd), nta. I think session-keyfile belongs here too (special case). They are written and read only by named and should not be edited manually. I think one common option would be enough for all of them. I think such files would normally belong somewhere into /var/lib/named directory. managed-keys and new-zone can be already configured by special option. /var/named/dynamic is used for them in RHEL. Maybe single per-view or global option "databases-directory" could be used for all of them? It might be useful to move these files into other directory, because data here are strictly instance specific. I could not find a better name for the option. 3) Read-only master zone files. Already signed files where keys are maintained by external tools or not signed at all. Relative to CWD or configurable per-zone. We want those protected by unix rights and SELinux. /var/named is used for them, I think because historic reasons. I think absolute path to other than home directory is the best recommendation. We did not recommend it before. 4) Dynamic zone files with journals. Used for slaves, dnssec auto maintained zones and zones with dynamic update enabled. They require read-write access. We want to use /var/named/dynamic and /var/named/slaves for them. Also relative to CWD or configurable per-zone. Makes sense to keep them relative to home or save them at home. > > Cheers, > Ondrej > Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: 65C6C973