On Tue, Oct 2, 2012 at 2:41 PM, Ard Biesheuvel <ard.biesheu...@gmail.com> wrote: > 2012/10/2 Kees Cook <keesc...@chromium.org>: >>> If desired, additional restrictions can be imposed by using the >>> security framework, e.g,, disallow non-final r-x mappings. >> >> Interesting; what kind of interface did you have in mind? > > The 'interface' we use is a LSM .ko which registers handlers for > mmap() and mprotect() that fail the respective invocations if the > passed arguments do not adhere to the policy.
Seems reasonable. >>>> It seems like there needs to be a sensible way to detect that this flag is >>>> available, though. >>> >>> I am open for suggestions to address this. Our particular >>> implementation of the loader (on an embedded system) tries to set it >>> on the first mmap invocation, and stops trying if it fails. Not the >>> most elegant approach, I know ... >> >> Actually, that seems easiest. >> >> Has there been any more progress on this patch over-all? > > No progress. Al, Andrew, anyone? Thoughts on this? (First email is https://lkml.org/lkml/2012/8/14/448) -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/