lkml.org 
[lkml]   [2003]   [May]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Announcement] "Exec Shield", new Linux security feature
FromArjan van de Ven <>
Date04 May 2003 10:49:17 +0200
On Sun, 2003-05-04 at 09:03, Calin A. Culianu wrote:
> 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.

would be easier to make a CAP_EXEC capability that bind can drop then ;)
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 12:35    [from the cache]
©2003-2008