BIND less restrictive modes and policy
Manuel Wolfshant
wolfy at nobugconsulting.ro
Tue Jan 22 09:28:48 UTC 2008
Andrew Farris wrote:
> Enrico Scholz wrote:
>> Andrew Farris <lordmorgul at gmail.com> writes:
>>
>>>> pz/ and the other parts of the chroot filesystem must be read-only
>>>> for named.
>>> And why exactly is that?
>>
>> To give only the required rights is a common and working practice for
>> years to secure daemons. Fedora should not forget classical ways
>> (own uid, chroot environments, restrictive permissions) just to give
>> something like "easier configuration" (where I can not see how mixing
>> all and everything into a single dir can ease configuration).
>
> I understand the idea behind minimum access restrictions; my
> reply/question was in regard to the use of the word 'must' which I
> assumed to be more than suggestion based on best practice (i.e. it
> won't work unless..).
No, Enrico's reply was based on best practices and common sense, not on
"mandatory, otherwise it will break things". Adam's suggestion will just
lower an already existing level of security.
> Anyway, that common practice is certainly not something that should be
> ignored lightly, but lets not confuse whether it is suggestion or
> necessity. (that is all I was asking)
>
> If anyone has reason to believe real *breakage* occurs due to the
> change Adam Tkac was suggesting I hope they speak up.
It will not break anything but best security practices, but will bring
no benefit either. I support 1000.00 % Enrico's view. Having a single
directory with all zone files will not bring anything useful. OTOH (this
is a digression, I know) it WOULD be useful if bind would include
support for real database backends.
FWIW: Ever since 2000 I do "split DNS" by running two different daemons,
chrooted each one it its own directory, rather then "different external
/ internal" views. If someone is to break my external named, (s)he will
(or should) be chroot-ed to external named's directory and hopefully
will not be able to find out information about my internal networks.
More information about the fedora-devel-list
mailing list