On Fri, Aug 27, 1999 at 12:13:15PM -0400, der Mouse wrote:
> [Replying to multiple messages here.]
> 
> > 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.
> 
> I'd suggest a way to configure these checks off - I can imagine uses
> for things like making mydaemon.core a FIFO.  While I've never wanted
> it, I am not prepared to say I never will.

In the current situation, dumping core to something else than a regular file
already doesn't work. The problem is that symlinks are followed before
checking.

> 
> >> This still has a potential race between the first and the second
> >> call to namei().
> > This would mean the kernel gets interrupted, and another process gets
> > runnable once IRQ is handled, rigth ?  Is this possible ?
> 
> Yes.  Consider, for example, what can happen if the core dump is going
> over NFS to a slow server.

Hum when this happens we have already open the file, rigth ?
Symlinks should,'t be resolved at this point.

> 
> > Just don't allow coredumps through symlinks, since it's of dubious
> > value now that corefiles are named "progname.core" anyway.
> 
> ...only by default; consider kern.shortcorename.  And even if they're
> not, symlinking testdaemon.core to somewhere else is not necessarily an
> unreasonable thing to do.
> 
> What exactly is the attack these changes are supposed to stop?  So far,
> the only one I've seen mentioned is the one where someone malicious
> leaves a symlink pointing to (say) /sbin/init or /etc/passwd lying
> around in /tmp or some such and then convinces a root-run process to
> drop core there.  This can be stopped by making coredumps to symlinks

The example here was to /root/.ssh/authorised_keys. With the rigth thing
in the process's memory dumping core, it works.

> fail unless the link is owned by the owner of the dumping process (or,
> arguably, root).

I proposed that ... Some people prefer to disable core to symlink completely.


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