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

From: PaX Team
Date: Sun Oct 07 2012 - 20:24:27 EST


On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote:

> 2012/10/6 PaX Team <pageexec@xxxxxxxxxxx>:
> > sadly, this is not true at all, for multiple reasons:
> >
> .. snip ...
> >
> > cheers,
> > PaX Team
> >
>
> So can I summarize your position as that there is no merit at all in
> the ability to inhibit future permissions of existing mappings?

i believe i answered this in the previous mail already:

> there's certainly a point (i've been doing it for 12 years now), but to
> make an mprotect flag into an actual security feature, it had better pass
> simple tests, such as non-circumventability. any method relying on
> userland playing nice is already suspect of being the wrong way and right
> now i don't see how PROT_FINAL could be used for actual security.

so if PROT_FINAL wants to be useful, you'd have to present a case of
how it does something useful *while* an exploited userland cannot get
around it. in fact i think i already told you that presenting your own
use case in more detail (read: source code, policy, etc) would be a
great step in 'selling the idea'. the fact that you seem to be reluctant
to follow up on this leaves me somewhat uneasy as it may be the sign
of a proprietary vendor's trying to push some code into mainline that
nobody else has a clear idea how it'd benefit the rest of us. you see,
you're asking for a change in a system call, which is a very important
boundary for kernel developers as they'll have to maintain it indefinitely.
so the burden is on you to prove that either this is the only way to
implement a useful feature or at least it is the optimal way as opposed
to other approaches. i suggested you ways to both attack the initially
presented concept and also how it may be improved, but i got no answers
to them yet.

cheers,
PaX Team

--
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/