Subject: Re: coredump following symlinks (3)
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Charles M. Hannum <root@ihack.net>
List: tech-kern
Date: 08/27/1999 12:50:09
This part of the patch:
+ if ((ndp->ni_vp->v_type == VLNK) &
+ ((fmode & FNOSYMLINK) != 0)) {
should read:
+ if (ndp->ni_vp->v_type == VLNK)
You should not be able to open(2) a symlink, regardless of flag
settings.
e I've never wanted
it, I am not prepared to say I never will.
>> 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.
> 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
fail unless the link is owned by the owner of the dumping process (or,
arguably, root).
>>> Do you have an idea on how to solve this ? I'm not really familiar
>>> with VFS ...
>> It's not specific to VFS; it's a classic security gotcha with any
>> kind of kernel where you check one thing and then operate on
>> another..
> Actually it's more like we operate on the same thing, but we relase
> the lock between the 2 operations.
This means that while you may *want* to operate on the same thing, you
have no assurance that you actually *do*.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B