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