Re: [Announcement] "Exec Shield", new Linux security feature

From: Valdis.Kletnieks@vt.edu
To: linux@horizon.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Sat, 03 May 2003 19:00:30 -0400	[thread overview]
Message-ID: <200305032300.h43N0UX9006675@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Sat, 03 May 2003 13:19:52 -0000." <20030503131952.5560.qmail@science.horizon.com>

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Sat, 03 May 2003 13:19:52 -0000, linux@horizon.com  said:

> An interesting question arises: is the number of useful interpreter
> functions (system, popen, exec*) sufficiently low that they could be
> removed from libc.so entirely and only staticly linked, so processes
> that didn't use them wouldn't even have them in their address space,
> and ones that did would have them at less predictible addresses?
> 
> Right now, I'm thinking only of functions that end up calling execve();
> are there any other sufficiently powerful interpreters hiding in common
> system libraries?  regexec()?

This does absolutely nothing to stop an exploit from providing its own
inline version of execve().  There's nothing in libc that a process can't
do itself, inline.

A better bet is using an LSM module that prohibits exec() calls from any
unauthorized combinations of running program/user/etc.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]