Messages in this thread | ![/](/images/icornerl.gif) | | From | Jesse Pollard <> | Subject | Re: [Announcement] "Exec Shield", new Linux security feature | Date | Mon, 5 May 2003 08:35:02 -0500 |
| |
On Sunday 04 May 2003 02: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..
What you actually would do is have the LSM module turn exec into MAY_EXEC_IF where the IF is done to match security context information to the binary being execed. ssh shouldn't exec (well most of the time anyway) a root shell. Instead it should switch security context, (including a security id and uid's/gids) first, then exec if the new security context is valid for what is being execed. (and the new securid is not necessarily selected from kernel mode - it may depend on network connection + user id/gids requested + security level permitted)
More complicated, but the full security context being switched to cannot be selected by the application itself.
> 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.
true. - 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/
| ![\](/images/icornerr.gif) |