bind chrooted, logging and SELinux = suffering

Pete Ehlke pde at
Thu Jun 2 11:25:14 UTC 2005

On Wed Jun 01, 2005 at 13:40:48 -0400, Jason Vas Dias wrote:
>On Wed, 2005-06-01 at 12:17, Pete Ehlke wrote:
>> On Wed Jun 01, 2005 at 11:46:16 -0400, Jason Vas Dias wrote:
>> >
>> >By default, Red Hat ships BIND with maximum security protection enabled,
>> >to counter known security vulnerabilities as mandated by our security
>> >response team.
>> >
>> You know, the 'known security vulnerabilities' chestnut just keeps
>> popping up. Please tell me- what 'known security vulnerabilities' have
>> you identified in current versions of BIND? 
>> NB: vulnerabilities in BIND 8 that date to 1999 do not count.
>> Vulnerabilities introduced by operating system flasw do not count. We're
>> talking current BIND here. What 'known security vulnerabilites' do you
>> see in current BIND that are not introduced by your own choice of OS?
>Our "choice of OS" introduces NO security vulnerabilities - 
>rather, it allows Red Hat to be the only vendor of a working
>SELinux system, which provides a more secure environment than 
>any other Linux distribution.

Thank you very much for the marketing material.

>The BIND SELinux policy was developed in close collaboration with the 
>NSA, in general to prevent:
>o Unauthorized Access to named's files by any other process than named
>  or the system administrator
>o Access to the data of other processes by a process masquerading as
>  named or by a named that had been "taken over" by poking executable
>  code into the running process image
>o Write access to named's files by a process masquerading as named
>  or by a named that had been "taken over" .
>o An easy escalation from the privileges of the "named:named" userid
>  to the "root:root" userid.

In other words, you have not identified any "known security
vulnerabilities' in current BIND. As a matter of policy, running
networked services inside a chroot, a jail, or a zone is a prudent
thing. But please stop using alarmist phrases like "Red Hat ships BIND
with maximum security protection enabled,to counter known security 
vulnerabilities." There are no known security vulnerabilities in modern

>The last three reasons are those typically given for running named in 
>a chroot environment, which is made unnecessary by SELinux protection.
>Also, we make attempts to alter or "take over" a running named binary
>virtually impossible, with our kernel and gcc ExecShield support 
>( see ),
>which is also not fully implemented by any other Linux vendor, and by
>compiling the named executable with the flags 
>'-pie -Wl,-z,relro,-z,now,-z,nodlopen,-z,noexecstack'
>which means: 
>"enable ExecShield protection; read-only relocation sections; 
> no deferred symbol resolution; dlopen not allowed; executable
> stack sections not allowed
>", and which makes any attempt to alter a named binary virtually

Thank you very much for the marketing material.

More information about the bind-users mailing list