On Thu, Nov 03, 2016 at 04:04:42AM +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. > > The new security hook security_forced_write() takes three arguments: > > - The modified VMA, so the security check can e.g. test for executability. > - The subject performing the access. For remote accesses, this may be > different from the target of the access. This can e.g. be used to create > a security policy that permits a privileged debugger to set software > breakpoints in the address space of a sandboxed process. > - The target of the access. This is useful if only a subset of the > processes on the system should be prevented from executing arbitrary > code, as is the case on Android. > > changed in v2: > - fix comment (Janis Danisevsk) > - simplify code a bit (Janis Danisevsk) > > changed in v3: > - rebase > - no need to pass in creds in populate_vma_page_range() > - reword check_vma_flags() comment (Ingo Molnar) > - use helper struct gup_creds (Ingo Molnar) I introduced some bugs here again, as the kernel test robot points out.
Attachment:
signature.asc
Description: Digital signature