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, email@example.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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:21 EST