| |||||||||||||
Tainting from user spaceTainting from user spacePosted May 25, 2006 19:46 UTC (Thu) by brouhaha (subscriber, #1698)In reply to: Tainting from user space by caitlinbestler Parent article: Tainting from user space Exactly the same point I was going to make. On the rare occasions when I've accessed physical memory from user space, I've done it by mmap()ing /dev/mem. Arguably any user process that mmap()s /dev/mem or /dev/kmem with write permission should result in a tainted flag, without any explicit request for that flag by the user process.
(Log in to post comments)
Tainting from user space Posted May 25, 2006 22:07 UTC (Thu) by deweerdt (subscriber, #18159) [Link] Except that mmaping /dev/mem with r/w permissions is exactly what every X process does... So a lot of kernels out there would be "tainted" in a way.
Tainting from user space Posted May 25, 2006 22:58 UTC (Thu) by brouhaha (subscriber, #1698) [Link] That's what I thought too, and certainly it's how it used to be done, but by now if it hasn't moved to mmap()ing a specific PCI region file, it certainly should.Back around 1999 I proposed that /proc/pci should have mmap()able files for each PCI memory region configured for a device. It looks like by 2003 this had been implemented, based on a post by David Miller to the LKML on 24-oct-2003. When I proposed that idea, it met a lot of resistance from people that thought it would somehow open a security hole. They didn't see that in fact it allowed BETTER control over security by using filesystem permissions to restrict an X server to only accessing the video card, and not being able to scribble over arbitrary memory. These days, with udev, it should even be possible to make the video card PCI regions owned by a specific user (e.g., "xserver"), and not give the X server root permissions at all.
|
|||||||||||||