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 <bouyer@antioche.lip6.fr>
>     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.

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