bind chrooted, logging and SELinux = suffering

[Jason Vas Dias]

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.
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.
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.
I hope that answers your questions.
Regards,
Jason Vas Dias.
Red Hat Inc.