Front page | perl.perl5.porters |
Postings from December 1999
Re: getspnam-support
Thread Previous
|
Thread Next
From:
John Macdonald
Date:
December 3, 1999 17:25
Subject:
Re: getspnam-support
Message ID:
199912040101.UAA23130@elegant.com
Dan Sugalski <dan@sidhe.org> writes:
|| At 02:19 PM 11/29/99 +0100, Matthias Urlichs wrote:
|| >Hi,
|| >
|| >Dan Sugalski:
|| >> >Returning the shadow data just because you're running as root is a
|| possible
|| >> >security hole.
|| >>
|| >> If you're running as root there are no security holes since there is no
|| >> security. You can already do anything you want, so why quibble over this?
|| >
|| >Consider a setuid-root program which doesn't need the actual password,
|| >but which calls getpw*() for other reasons.
|| >
|| >Conceivably, that program could be induced to leak the password.
||
|| Sorry, don't buy it. That'd require some odd tricks to get the password, as
|| the program'd have to explicitly ask for it anyway, and why ask if it's not
|| necessary? Either the program needs the password and therefore the
|| discussion is moot, or it doesn't and has thus been crocked somehow anyway.
But the program may not need the password. It might need the home
directory, login shell, or GCOS info, and the password just comes
along for the ride.
|| Plus anything running as root had darned well better be beyond
|| extra-careful in the first place, so presumably the vigilant programmer
|| would have checked for something like this in the first place.
A program can be written to be run by a regular user, and yet
be run (on occassion) by root. If the actual password was provided
only for an explicit getspw* call and '*' password was provided for
a getpw* call, programs would have to deliverately choose to have
security-critical information lying around in their memory --
obscure attacks would be not possible on programs that never got
the info in the first place. Programs that need the password must
be designed with security in mind, but programs that don't need
shouldn't be held to the same standard.
--
John Macdonald jmm@jmm.pickering.elegant.com
Thread Previous
|
Thread Next