bind chrooted, logging and SELinux = suffering
Jason Vas Dias
jvdias at redhat.com
Wed Jun 1 17:40:48 UTC 2005
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.
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
"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
I hope that answers your questions.
Jason Vas Dias.
Red Hat Inc.
More information about the bind-users