Re: Hiding username/password from ps

From: Peter David THOMPSON <pdt_at_cs.mu.OZ.AU>
Date: 1995/12/28
Message-ID: <9536220.2748_at_mulga.cs.mu.OZ.AU>#1/1


dmarcus_at_notes.cc.bellcore.com (Dave Marcus) writes:

>In article <4armcg$kv9_at_news.compulink.gr>, xeno_at_athena.compulink.gr says...
>>
>>Just compile a 'ps' of your own that calls the real ps
>>but with option to restrict the display of the command.
>>
>A WAY TO HIDE USERNAME/PASSWORD FROM PS
 
>- hardcode the password in a file (with the proper permissions)
>- sqlplus username _at_file.sql < password.file
 

>The password will not appear (you can put the username in there too
>if you want). If you don't like hardcoding passwords, this is not
>for you

Ummmm... let me just point out here the minor difficulties with this scheme.

  1. If you can < a file, you can read it using <gasp!> such hacker's tools as cat and more.
  2. If you use accept in any of your scripts, you are going to be dead.

It's possible to make a sqlplus-alike that feeds the username & password to sqlplus and then copies stdin to stdout (20 lines or so of C code). Of course, you neet to run your application setgid (NOT THE PASSWORD FEEDER!) and make the password feeder executable only by group; the same sort of thing makes objection 1) a bit moot, as well.

On the other hand, to make the original suggestion work, all you have to do is your own ps, make it setgid kmem (or your local equivalent), and remove setgid from the real ps (which you should rename).

Of course, this is your basic scorched-earth solution, but hey - whatever makes you happy. You could try OPS$ oracle accounts, I suppose.

Think about what you're trying to do:

  1. Stop Joe Blow from doing the stuff that J. Random President can?
  2. Restrict access to the database except through the application?
  3. Implement the kind of security policy that makes users give thier passwords to each other?
  4. Roach-proof your system? (Roach is a better term than hacker IMHO).

pdt.

-- 
My own opinion, worth what you paid me for it.
Received on Thu Dec 28 1995 - 00:00:00 CET

Original text of this message