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

Re: BIND less restrictive modes and policy



Manuel Wolfshant wrote:
On 01/22/2008 03:17 AM, Andrew Farris wrote:
Enrico Scholz wrote:
Adam Tkac <atkac redhat com> writes:

Also complete /var/named/* subtree will be writable by named

This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable.
pz/ and the other parts of the chroot filesystem must be read-only for
named.

And why exactly is that? Any reference or reason? What becomes exploitable if that is changed?

Bind DID have security issues in the past, providing remote root. Just because we have selinux and that as far as we know NOW there are no atack methods is not a reason to lower the difficulty bar. Just give any application the minimum rights needed to do what it has to do. Any method which raises the difficulty bar for a potential attacker -- especially when it is already available and taking into consideration potential DNS poisoning attacks -- is good. Lowering the bar with no real gain is bad.

Absolutely agreed as to the best practice ideas there, generally... but you didn't say it was just 'bad' you said it 'must be read-only'. This is very different. I was asking for clarification as to why it must be, not why it would be better not to be. (but I think you answered that now in a way)

I'm assuming now that:
>>> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be
>>> writable.

is necessary to function

>>> pz/ and the other parts of the chroot filesystem must be read-only for
>>> named.

is not necessary, only 'a good idea', a change to which you are against

--
Andrew Farris <lordmorgul gmail com> <ajfarris gmail com>
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----


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