Dave Hansen <d...@sr71.net> writes: > From: Dave Hansen <dave.han...@linux.intel.com> > > Physical addresses are sensitive information. There are > existing, known exploits that are made easier if physical > information is available. Here is one example: > > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf > > If you know the physical address of something you also know at > which kernel virtual address you can find something (modulo > highmem). It means that things that keep the kernel from > accessing user mappings (like SMAP/SMEP) can be worked around > because the _kernel_ mapping can get used instead. > > But, /proc/$pid/pagemap exposes the physical addresses of all > pages accessible to userspace. This works against all of the > efforts to keep kernel addresses out of places where unprivileged > apps can find them. > > This patch introduces a "paranoid" option for /proc. It can be > enabled like this: > > mount -o remount,paranoid /proc > > Or when /proc is mounted initially. When 'paranoid' mode is > active, opens to /proc/$pid/pagemap will return -EPERM for users > without CAP_SYS_RAWIO. It can be disabled like this: > > mount -o remount,notparanoid /proc > > The option is applied to the pid namespace, so an app that wanted > a separate policy from the rest of the system could get run in > its own pid namespace. > > I'm not really that stuck on the name. I'm not opposed to making > it apply only to pagemap or to giving it a pagemap-specific > name. > > pagemap is also the kind of feature that could be used to escalate > privileged from root in to the kernel. It probably needs to be > protected in the same way that /dev/mem or module loading is in > cases where the kernel needs to be protected from root, thus the > choice to use CAP_SYS_RAWIO.
There is already a way to make pagemap go away. It is called CONFIG_PROC_PAGE_MONITOR. I suspect the right answer here is if you enable kernel address randomization you disable CONFIG_PROC_PAGE_MONTIOR. Aka you make the two options conflict with each other. That is a lot less code and a lot less to maintain. On the other hand if this is truly a valuable interface that you can't part with we need an alternative to pagemaps that does the same job with out the exploit potential. And I don't how to do that. Arguing in favor of just making the options conflict is the fact that kernel address randomization is pretty much snake oil. At least on x86_64 the address pool is so small it can be trivially brute forced. I think there are maybe 10 bits you can randomize within. As for a way to disable this I expect it would do better with something like a set once flag that prevents a process and all of it's children from accessing this file. *Blink* *Blink* Did you say you are worried about escalting privileges from root into the kernel space. That is non-sense. We give root the power to shot themselves in the foot and any proc option will be something that root will be able to get around. The pieces of the patch description don't add up. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
