Messages in this thread | | | Date | Wed, 3 Jun 2009 10:21:23 -0700 | From | "Larry H." <> | Subject | Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space) |
| |
On 12:36 Wed 03 Jun , Rik van Riel wrote: > Larry H. wrote: > >> Christopher, crippling the system is truly not the way to fix this. >> There are many legitimate users of private|fixed mappings at 0. In >> addition, if you want to go ahead and break POSIX, at least make sure >> your patch closes the loophole. > > I suspect there aren't many at all, and restricting them through > SELinux may be enough to mitigate the risk.
It's still perfectly valid POSIX, but I'm definitely keen on using this patch together with a convenient mmap_min_addr value. I'm just trying to show how both things are orthogonal to each other, without additional cost for us (as in people doing kernel/drivers development) and users.
>> If SELinux isn't present, that's not useful. If mmap_min_addr is >> enabled, that still won't solve what my original, utterly simple patch >> fixes. > > Would anybody paranoid run their system without SELinux?
Does everyone who is conscious about security must use SELinux? Is SELinux the only acceptable solution? What about people who decide to use AppArmor, or LIDS, or grsecurity?
That's not a valid point. People should stay safe without SELinux whenever it is feasible, IMHO. I think everyone here will agree that SELinux has a track of being disabled by users after installation because they don't want to invest the necessary time on understanding and learning the policy language or management tools.
>> The patch provides a no-impact, clean solution to prevent kmalloc(0) >> situations from becoming a security hazard. Nothing else. > > True, the changes in your patch only affect a few code paths.
Only SLAB code itself is affected, users of kmalloc won't see a functional difference. They just won't be as easily abused if a zero length ends up passed to kmalloc and the pointer is used for something later. There's an issue here that I must note: a wraparound can happen and make the pointer land back somewhere near NULL.
It could be changed to point at the start of the fixmap.
It might be wise to see if expanding the fixmap on runtime can deter this, although I had trouble using it within vm guests. This can be done using reservetop boot option.
Larry
| |