bind chrooted, logging and SELinux = suffering

Pete Ehlke pde at rfc822.net
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.

>See: http://www.nsa.gov/selinux 
>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
BINDs.

>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 http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf ),
>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
>impossible.

Thank you very much for the marketing material.



More information about the bind-users mailing list