[1081] in linux-net channel archive
Re: Rewrite DIP-337n-inaky to handle script file encryption
daemon@ATHENA.MIT.EDU (Steven P. Crain)
Sun Sep 10 06:32:27 1995
Date: Fri, 8 Sep 1995 09:15:58 -0400 (EDT)
From: "Steven P. Crain" <scrain@goddard.shore.net>
To: raju@xgroup.ernet.in
cc: linux-net@vger.rutgers.edu, linux-apps@vger.rutgers.edu
In-Reply-To: <m0sqVYD-000CBSC@gratis.xgroup.ernet.in>
On Thu, 7 Sep 1995, Raj Mathur wrote:
> >>>>> "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.
>
Another possibility would be to modify dip to replace $PASSWD (or
whatever) in its scripts with a string from the encrypted file ~/.passwd
instead of encrypting the whole file. If you stored several strings in
this file you could do even more with the security.
It's not entirely secure, but you could use the same key for all users,
have it compiled into dip, and not allow anyone to use any file
other than ~/.passwd (or perhaps better ~/.dippasswd). The key could be
a compile time option (so that its not lying around in the source).
Problems: Somebody copying ~another_user/.dippasswd into ~/.dippasswd
(this could be plugged by combining the user with the system key and an
optional user key to create the key to the file).
Somebody extracting the key from the executable (e.g. with a core dump if
they don't have read permission).
Perhaps others.
It should be more secure than nothing, however.
Steven P. Crain scrain@goddard.shore.net
------------------------------------------------------------------------------
Assistant for Library Automation
Goddard Library http://www.shore.net/~goddard
Gordon-Conwell Theological Seminary gopher://gopher.shore.net/members/anderson
------------------------------------------------------------------------------
I am Colonel Klemmens Lothar Wenzel Friedrich Conrad,
Freiherr von Uegelpflaetz.
I am Pondering Owl, or Steve{,n,n P.} {,Crain}.
But I am definitely *not* Mr. Crain.
