 |
 |
> -----Original Message----- > From: Testbed Support for GridPP member institutes [mailto:TB- > [log in to unmask]] On Behalf Of Ewan MacMahon > Sent: 14 August 2009 17:59 > To: [log in to unmask] > Subject: Re: Regarding CVE-2009-2692 local root vulnerability, exploits in > the wild > > > -----Original Message----- > > From: Testbed Support for GridPP member institutes [mailto:TB- > > [log in to unmask]] On Behalf Of Ma, Mingchao (STFC,RAL,ESC) > > > > Hi all, > <snip> > > > > Apart from the advices you received via EGEE CSIRTs mailing list, you > > should check: > > > > - If the kernel support mmap_min_addr, if it does, then set > it > > greater than zero; > > > It appears to default to 65536 on a plain SL5 x86_64 install, so for > most > of us the systems that support mmap_min_addr are probably already > actually > using it. No really. Here is the bug report "selinux policy allows addr 0 mappings by default" https://bugzilla.redhat.com/show_bug.cgi?id=511143 no patch released. Last updated is 2009-08-12 Basically it does not matter if mmap_min_addr is set or not on RH5, selinux will bypass it anyway. Here is the reason (from SELinux team) why Selinux does not check mmap_min_addr: http://eparis.livejournal.com/606.html In this particular case, enable SElinux makes the system (RH5) more vulnerable. > > > - Disable the SELinux if you can until update is available; > > > Bear in mind that this advice only applies to SL5 systems - the presence > or otherwise of SElinux makes no difference on SL4. It is because SL4 does not support mmap_min_addr. > Also, as Dug notes, SL5 seems to enable bluetooth support by default; > however if you do 'chkconfig bluetooth off' it doesn't even attempt to > load the bluetooth kernel modules, so while it's still a good idea to > blacklist the kernel module, also turning the service off will avoid > any fallout from it trying to load and failing. > > Ewan