On Thu, Nov 03, 2016 at 04:04:45AM +0100, Jann Horn wrote: > SELinux attempts to make it possible to whitelist trustworthy sources of > code that may be mapped into memory, and Android makes use of this feature. > To prevent an attacker from bypassing this by modifying R+X memory through > /proc/$pid/mem, PTRACE_POKETEXT or DMA, it is necessary to call a security > hook in check_vma_flags(). > > PTRACE_POKETEXT can also be mitigated by blocking ptrace access, and > /proc/$pid/mem can also be blocked at the VFS layer, but DMA is harder to > deal with: Some driver functions (e.g. videobuf_dma_init_user_locked) > write to user-specified DMA mappings even if those mappings are readonly > or R+X. Whoops, sorry for sending that twice. :/ A comment regarding the whole series: I'm not entirely sure whether this is the best way to fix this after all. It's quite a bit of code churn, but it has the benefit of having a single check in a central place. As an alternative to this patch, it might be possible to break the ABIs of the drivers that access DMA buffers with FOLL_FORCE by simply removing FOLL_FORCE from those drivers. However, I'm not sure how much that would break existing userspace code.
Attachment:
signature.asc
Description: Digital signature