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

["Calin A. Culianu" <calin@ajvar.org>]

On Sat, 3 May 2003 Valdis.Kletnieks@vt.edu wrote:

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

Is that practical?  I can see how with some daemons it would definitely be
useful to prohibit exec calls (maybe things like BIND don't need to exec
anything).. but some daemons do need to exec.  An SMTPD may need to exec()
some helper processes (postfix for instance has a whole slew of helper
programs it uses).. and things like sshd need to exec a shell, etc..

It's still a good idea though, since some daemons don't need to exec,
ever.  I guess this is one extra layer of protection.  As Ingo said in his
announcement, the more layers of protection you have, the better.. and the
more difficult a cracker's job is.

-Calin