Date: Sun, 4 May 2003 09:51:51 -0400 (EDT)
From: Ingo Molnar <mingo@redhat.com>
To: Yoav Weiss <ml-lkml@unpatched.org>
cc: linux-kernel@vger.kernel.org
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
In-Reply-To: <Pine.LNX.4.44.0305041337590.31429-100000@marcellos.corky.net>
Message-ID: <Pine.LNX.4.44.0305040948390.31649-100000@devserv.devel.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1346
Lines: 34


On Sun, 4 May 2003, Yoav Weiss wrote:

> I don't see how the case of mprotect(HIGH_ADDRESS, LEN, PROT_EXEC) be
> handled.  Unlike mremap, mprotect doesn't offer a way to inform the user
> about a change of address.
> 
> If I understand correctly, such case will cause a call to
> arch_add_exec_range(current->mm, vma) without any remapping, thus
> breaking the protection.

yes - the patch does not put any limit on which areas can be PROT_EXEC -
if the executable area is 'too wide' then there's no protection. The patch
tries to relocate areas which are freely relocatable, to make sure that in
the usual case the exec-limit will be quite low.

> One case where this would happen is some of the ancient loaders.  IIRC,
> libc4's loader did just that.  (right, nobody uses it anymore :)

yeah, we should not be worried about old loaders.

> For that reason, maybe X_workaround should be controlled per-executable
> by another ELF flag and not as a system-wide property.

i'll remove X_workaround from the next patch altogether - X can be fixed
by enabling an executable stack for the binary.

	Ingo

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