Skip Menu |
Report information
The Basics
Id: 46242
Status: open
Priority: 0/
Queue: bind9-public

People
Owner: Nobody in particular
Requestors: Petr Menšík <pemensik@redhat.com>
Cc:
AdminCc:

Bug Information
Version Fixed: (no value)
Version Found: (no value)
Versions Affected: (no value)
Versions Planned: (no value)
Priority: (no value)
Severity: (no value)
CVSS Score: (no value)
CVE ID: (no value)
Component: (no value)
Area: (no value)

Dates
Created:Tue, 10 Oct 2017 10:29:22 -0400
Updated:Wed, 01 Nov 2017 17:48:16 -0400
Closed:Not set



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Date: Tue, 10 Oct 2017 16:29:13 +0200
From: "Petr Menšík" <pemensik@redhat.com>
To: bind-suggest@isc.org
Subject: [PATCH] nta-directory support
Download (untitled) / with headers
text/plain 1.7KiB
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. New feature Negative Trust Anchor was added in BIND 9.11 for short term DNSSEC exceptions. Because there is no configuration option to move NTA files into different directory, it will always fail to save the file on Fedora 26+. Because current implementation first opens the file and only then checks if NTA is even used or non-empty, it will log error on every shutdown. (Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1487823) I attached patch to provide configuration option to save nta files into custom subdirectory. That would allow stored NTA to be permanently saved into subdirectory where writing is allowed. It is a little unfortunate that it will try to save exceptions only on shutdown. If saving fails, NTA entries are lost without possibility to fixing permissions/freeing space and retry. It logs failure, but you can react next time only. I guess NTA store/loading is still simple to avoid synchronization and locking problems. I made a change to populate default view nta_file with NULL value from dns_view_create(). It is changed after calling dns_view_ntapermanent(). This way internal views (_bind) NTAs are not stored permanently. I think that should be ok, shouldn't it? Before it always created files for any view and deleted empty ones afterwards. This change will load, save and delete only files from views where dns_view_ntapermanent() were called. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: 65C6C973

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 1.2KiB
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 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). I think that adding more and more directives to scatter individual writeable directories across the filesystem just doesn't make much sense. Cheers, Ondrej
CC: "Tomas Hozza" <thozza@redhat.com>
From: "Petr Menšík" <pemensik@redhat.com>
To: bind9-public@isc.org
Subject: Re: [ISC-Bugs #46242] [PATCH] nta-directory support
Date: Fri, 27 Oct 2017 17:47:29 +0200
Download (untitled) / with headers
text/plain 6.1KiB
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
Subject: Re: [ISC-Bugs #46242] [PATCH] nta-directory support
Date: Wed, 1 Nov 2017 17:48:09 -0400 (EDT)
To: bind9-public@isc.org
From: "Petr Mensik" <pemensik@redhat.com>
Hi Ondra, I prepared two new patches. First one adds databases-directory option, that managed-keys, rndc addzone and rndc nta will all use. I think it might be useful for moving files to different place than authoritative data. It will work for all mkeys, nzf files and nta files. Second patch would remove support for new-zones-directory, because databases-directory can be used instead and it was not yet released in normal release. Would this patch be more acceptable? Kind regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: 65C6C973 ----- Original Message ----- From: "Ondrej Sury via RT" <bind9-public@isc.org> To: pemensik@redhat.com Sent: Tuesday, October 10, 2017 5:01:34 PM Subject: [ISC-Bugs #46242] [PATCH] nta-directory support 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 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). I think that adding more and more directives to scatter individual writeable directories across the filesystem just doesn't make much sense. Cheers, Ondrej

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.