bind chrooted, logging and SELinux = suffering

[Jason Vas Dias]

On Thu, 2005-06-02 at 07:25, Pete Ehlke wrote:
> 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.
> 
So why is it a "prudent thing" to run BIND in a chroot jail, if there
are no security reasons for it ?
All I was saying was that SELinux addresses the same issues as are
met by running BIND in a chroot, but in a far more secure manner .
 
> >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.
> 
No problem - you did ask for the reasons for our BIND SELinux policy.
I tried to explain them to you.