On Fri, Aug 27, 1999 at 02:40:27PM +0100, Roger Brooks wrote:
> Well the danger is usually from a setuid process dumping core and some
> versions of unix don't allow setuid programs to dump core (HP-UX used to
> be like this).  So I suppose you could add a sysctl which would switch
> this behaviour off or on.

This is already disabled in NetBSD. The problem here is when you can convince
a process run by root (the 'find' run from /etc/rc, /etc/security or
/etc/daily in this case) to dump core. This one is not suid.

> 
> But it's sometimes very useful to be able to move a core dump into another
> filesystem with a symbolic link, particularly if you have an obscure bug
> in a daemon and there isn't room for the coredump in / (or wherever its
> CWD is).  I have another couple of ideas which might help:
> 
> 1.  Modify the code which generates the coredump so that if the program is
>     setuid, the core file is opened with the real uid (and gid).
> 
> 2.  Have the coredump code lstat the prospective core file.  If it's a
>     symbolic link which points to an existing file, read it for a magic
>     number and only let the coredump happen if the file already contains
>     a coredump.
> 
> 
> If you were to do both the above I think you'd have prevented tricks based
> on symlinking core to /etc/passwd and then making a setuid-root program drop
> core.

But not the trick used for this problem.
What I'll be doing is
1) only dump core on regular files or regular files pionted by symlinks.
2) only dump core if the file (or the symlink) is owned by the process UID.

This way it should not possible to convince a root process to follow a
non-root symlink.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--