Subject: Re: coredump following symlinks
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 08/27/1999 16:23:33
On Fri, Aug 27, 1999 at 11:29:58PM +1000, Robert Elz wrote:
> Date: Fri, 27 Aug 1999 15:17:38 +0200
> From: Manuel Bouyer <email@example.com>
> Message-ID: <19990827151738.A669@antioche.lip6.fr>
> | Why not 'limit coredumpsize 0' then ?
> Ugh. csh (make suitable warding off signs...). Try: ulimit -c 0
> (which I know that you know Manuel...)
armandeche:/users/cao1/bouyer>ulimit -c 0
ulimit: Command not found.
I'm using tcsh :)
> | For security I'd really like to be able to disable core dumps on symlinks.
> | Would a sysctl be an option ?
> Since there are more checks being done anyway (and the cost of doing a
> core dump doesn't really matter anyway), perhaps allow a symlink if the
> symlink is owned by the user for whom the core dump is being done.
> I'm not sure that this will avoid all possible problems, but it certainly
> beats the easy case where you just create a symlink and then convince a
> root run prog to dump cor eon top of it.
> Of course the real fix for these problems is to fix the programs that
> root is running (via automater scripts, so it is reasonably possible for
> an intruder type to depend upon them being run) so they don't dump core.
I agree. But how are you sure none of the automatically-run program will not
dump core ? We can audit the NetBSD tree, yes. But what about pkgsrc ?
What about homegrown programs ?
I strongly believe that avoiding this kind of attack is a good thing.
> Dumping core because of a long path name is really a pretty basic kind
> of bug - and if the root run program has that bug, it most likely has
> your typical "buffer overrun" type (execute my code please) type bug as
Well, not sure. You can get core dumps for other reasons than a buffer overlow
on the stack.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr