[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: BIND less restrictive modes and policy



Andrew Farris wrote:
Enrico Scholz wrote:
Andrew Farris <lordmorgul 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]