[1074] in linux-net channel archive
Re: Rewrite DIP-337n-inaky to handle script file encryption
daemon@ATHENA.MIT.EDU (Raj Mathur)
Sun Sep 10 04:35:32 1995
Date: Thu, 7 Sep 95 06:44 IST(+0530)
From: raju@gratis.xgroup.ernet.in (Raj Mathur)
To: scrain@goddard.shore.net
Cc: linux-net@vger.rutgers.edu, linux-apps@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.91.950906130456.660C-100000@goddard.shore.net> (scrain@goddard.shore.net)
Reply-To: raju@xgroup.ernet.in
>>>>> "Steven" == Steven P Crain <scrain@goddard.shore.net> writes:
Steven> On Mon, 4 Sep 1995, Raj Mathur wrote:
>> DIP is very nice except for minor irritant -- I hate to see
>> unencrypted passwords lying around in script files. I agree
>> that the user can be prompted to enter the login and password
>> once the connection is made, but that won't work for an
>> unattended shell script or cron job. To take care of this
>> problem I'm proposing to do a bit of rewriting which allows DIP
>> to handle encrypted script files, with the pass{word,phrase} to
>> be given once by the user (perhaps as an environment variable).
>> Subsequently when DIP starts up (with the new -d option?) it
>> uses this password to decrypt the script file and runs it.
>> [etc.]
Steven> I wonder if you can come up with a way to do this that can
Steven> be used more generally, perhaps with most programs that
Steven> access security-important files.
Hmm, that makes sense. However, at first sight I'd say that each
program would need to be modified individually, since we don't want to
just decrypt a file, push it's contents into another file and pass the
new filename to the program: then the system is as secure as the file
itself. Is there any method of creating an *anonymous* file in
Linux/UNIX? I.e. to say, a file which doesn't appear in any directory
listing and is only available to programs satisfying some
(indeterminate as of now) criteria?
Apologies to many readers of the original posting who have pointed out
that passing a password in the environment is not secure. I knew that,
and had some nebulous idea of (1) passing the password itself
encrypted and (2) having DIP zero out the appropriate variable as soon
as it had copied it to another memory location. Sorry about the
misunderstanding, and I guess the nebulosity needs to be reduced,
pronto :)
-- Raju
--
Raj Mathur The X Group New Delhi India
PGP: Fingerprint: F2 D4 4A 21 27 B0 63 FF 15 97 9D AE 9D 40 BC B8
2.6.i Key: finger raju@arbornet.org
It is the mind that moves.