elf_set_personality()

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Feb 27, 2012 at 12:09:00PM -0500, Robert Love wrote:
> On Mon, Feb 27, 2012 at 11:41 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > It seems that vanilla mmap() of a file does not deny a mapping containing
> > PROT_EXEC of a file with read-write-noexec permissions - it permits it,
> > but it does fail mapping a file PROT_WRITE which wasn't opened for write.
> >
> > Moreover, it's not actually possible to prevent execution of code if
> > you have read permission - if you can read a mapping, you can copy it
> > into an executable mapping and then execute copied code.
> >
> > So, I don't think there's any reason to prevent PROT_EXEC in a hard and
> > fast manner. ?If you don't want to go that far, what about:
> >
> > ? ? ? ?prot_mask = PROT_MASK;
> > ? ? ? ?if (current->personality & READ_IMPLIES_EXEC)
> > ? ? ? ? ? ? ? ?prot_mask &= ~PROT_EXEC;
> > ? ? ? ?if (vma->vm_flags & ~asma->prot_mask & prot_mask) {
> > ? ? ? ? ? ? ? ?ret = -EPERM;
> > ? ? ? ? ? ? ? ?goto out;
> > ? ? ? ?}
> >
> > which would mean !READ_IMPLIES_EXEC threads would get the full permission
> > checking, but a READ_IMPLIES_EXEC thread would still be able to attach
> > to a r/w only shared mapping.
> 
> ashmem should behave however vanilla mmap behaves.

Well, it's fairly clear that it doesn't, because it has more stringent
permission checks than vanilla mmap.

> There is no reason to be different and I'd prefer to consolidate or at
> least copy the code.
> 
> It is unfortunate that each implementer of fops->mmap needs to
> manually handle the READ_IMPLIES_EXEC case.

That would mean ignoring PROT_EXEC entirely.