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