Subject: Re: sysctl knob to let sugid processes dump core (pr 15994)
To: Elad Efrat <elad@NetBSD.org>
From: Garrett D'Amore <email@example.com>
Date: 01/13/2006 11:16:43
Elad Efrat wrote:
>Garrett D'Amore wrote:
>>These checks maybe should be enabled by yet another sysctl, in case some
>>site has some special reason not to enforce them.
>It seems like this is getting way too bloated. The original request was
>for a knob to be used on development machines; I'm not sure who would
>want to enable such a feature on a production box.
>The suggestion of setting a directory and owner via sysctl seems enough
>for me; root should take care of anything around it.
Here's the scenario I see, and it should be thought out:
Site has a big database server, maybe its in production.
For some reason the database server (or a supporting component)
needs to run suid or sgid, and it needs to be debugged. Possibly the
failure that needs debugging can only be reproduced under load.
Imagine also the database contains some sensitive data, or that the
main database server is mission critical and can't take downtime.
If I'm a 3rd party contractor responsible for the failing code, I'm
likely to want to just enable the tunable so I can debug my app. I
think debugging this application should not be able to take down the
whole server. (Especially if the code I'm debugging runs suid as some
user *other* than root.)
Imagine this attack: malicious user drops in a symlink from /var/core to
/. Site doesn't use this for many months, but then either turns this
feature on, or perhaps the first core dump occurs many months later.
The process of dumping core now clobbers the root filesystem, and I have
a major outage.
Its important if you're going to create files, especially if you're
going to create them suid root (or effectively so by default user), that
you make absolutely certain that it be done safely. Even though you
think of this as a development only feature, if you expose it and
document it, then it will get used even on production boxes to assist
with debugging of problems. *Especially* when this feature is useful
for debugging 3rd party application code.
If we don't do this, then we had better darn well make sure that the
security implications of enabling this tunable are well documented
wherever we document the existence of the feature.
Garrett D'Amore http://www.tadpolecomputer.com/
Sr. Staff Engineer Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc. Phone: (951) 325-2134