BIND less restrictive modes and policy

Andrew Farris lordmorgul at gmail.com
Tue Jan 22 02:57:20 UTC 2008


Manuel Wolfshant wrote:
> On 01/22/2008 03:17 AM, Andrew Farris wrote:
>> Enrico Scholz wrote:
>>> Adam Tkac <atkac at 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 at gmail.com> <ajfarris at 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
----                                                                       ----




More information about the fedora-devel-list mailing list