Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

[Ard Biesheuvel]

2012/10/4 Mikael Pettersson <mikpe@xxxxxxxx>:
> - If .text is mapped non-writable and final, how would a debugger
>   (or any ptrace-using monitor-like application) plant a large
>   number of breakpoints in a target process? Breakpoint registers
>   aren't enough because (a) they're few in number, and (b) not
>   all CPUs have them.
>

ptrace() doesn't care whether or not the process itself can write to
its .text segment.

> - You're proposing to give one component (the dynamic linker/
>   loader) absolute power to impose new policies on all
>   applications. How would an application that _deliberately_
>   does something the new policies don't allow tell the dynamic
>   linker or kernel to get out of its way?
>

You are debating cases in which the userland would choose not to use
the feature. That is exactly the point of this patch: the kernel
supplies the feature and it is up to the userland to use it when
desired. If not in the loader, perhaps processes running setuid
binaries or browser sandboxes could choose to call mprotect() to
finalize some of their existing mappings (their stack?) before handing
over to less trusted code or opening up to the network.

> This clearly changes the de-facto ABIs, and as such I think
> it needs much more detailed analysis than what you've done
> here.
>

Could we at least agree on the fundamental notion that the special
powers the loader has to modify .text and .rodata sections are hardly
ever needed by the programs themselves? In that sense, this is similar
to dropping root privileges when not required anymore, and that is
typically recognized as a sensible idea.

> At the very least I think this change should be opt-in, but
> that would require a kernel option or sysctl, or some config
> file for the user-space dynamic linker/loader.

As long as the kernel does not impose its use, I don't see a reason
for an interface into the kernel to deactivate it.
I would be interested in learning about example cases that have a
valid need to modify their own code and constant data, as
understanding those would greatly help in designing the ways userland
should be able to have control over this.

Regards,
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/