4

I have a script that a member of our L1 team will run on a linux server (ssh'ed in - non root) that will take in their password and pass it to kinit via an embedded expect script (which ultimately talks to our authentication Kerberos KDCs) for the sake of running a ready for business check.

A consideration was to use getpass2 python but that's not available inhouse. A possible solution exists via a shell script using:

read -s -p "Password for $USER: " PASS

I've read through this blog. The author claims

Between the prompt and the shell execution, the password is in cleartext .

Are there steps to take to mitigate this?

I realize the password is in cleartext in RAM as well - but this is a separate issue for now.

james6125
  • 211
  • 1
  • 8
  • 1
    What threat are you trying to protect against? Obviously it'll have to be plaintext when they enter it and when it's sent to Kerberos, so what advantage do you gain by encrypting & decrypting it in between? – AndrolGenhald Apr 04 '18 at 17:40
  • 1
    The password never gets sent to the KDCs. I've clarified the use. My intent is to read in a password as securely as possible. If you think it's a non issue, I'm open to your reasoning why. – james6125 Apr 05 '18 at 01:07
  • 1
    You should never be processing sensitive data using a shell script. – forest Apr 05 '18 at 01:54
  • Thanks forest. Do you have any suggestions for moving the use case forward? – james6125 Apr 05 '18 at 21:28
  • That depends on exactly what you need to do. You may be able to use PAM for authentication. – forest Apr 06 '18 at 05:44

3 Answers3

3

You assume (as do a lot of people whom should know better) that when you input a password there is some some magic mojo protecting its cleartext in the program. If you can assure the integrity of the program reading the password and it does not deliberately persist or export the cleartext, then it will not be accessible to other programs.

A script is slightly easier to compromise than a binary program assuming that the attacker has root level access to the filesystem - but at that point its already pretty much game-over. There is an argument that if the program is swapped out of memory, then the cleartext will persist on the swap space - but that is almost the same problem as protecting the RAM (you shouldn't be using remote storage for swap anyway).

Update Sergey's answer appears to address what you do with the password after you have captured the cleartext (although its not very clear). But if you are using a shell builtin to inject the password into the target program it will not appear in the output of 'ps'

symcbean
  • 18,278
  • 39
  • 73
0

Each non-builtin command in scripts appears as separate process, so from the cited blog example PASS ( which should be quoted, btw, to avoid word splitting ) will appear on ps output.

See also https://unix.stackexchange.com/q/298178/85039 and https://stackoverflow.com/q/3830823/3701431 for possible ways to solve it

There are also security implications of word splitting: https://unix.stackexchange.com/q/171346/85039

Sergiy Kolodyazhnyy
  • 519
  • 5
  • 17
  • 2
    There is nothing in the OP's question about how the password is used after it has been captured by the script. "Each command in scripts appears as separate process" - that's not true, only if the command is a seperate binary. Most shells (and we're probably talking about bash here) have a large set of builtin commands including echo which will not appear in as new processes. – symcbean Apr 05 '18 at 09:21
  • @symcbean Good point about built-ins, I'll edit that. As for "how password is used after it has been captured", if they use `read` to capture password into a variable, and point to blog post that is doing exactly same thing, it's reasonable to assume that's what they're doing, no ? Unless they're placing password into command's environment, which is still accessible via `/proc//environ` – Sergiy Kolodyazhnyy Apr 05 '18 at 17:27
  • Thanks. We will not be passing the password to a command as a parameter but will engage an expect script to spawn kinit repeatedly. – james6125 Apr 05 '18 at 21:15
0

kinit has its own facility for password input. For example...

$ kinit user@realm Enter password for user@realm:

I would suggest the tools input method which is already hiding the input from the terminal

jas-
  • 931
  • 5
  • 9
  • Thanks. The point of the script is to reduce the number of times the analyst enters the password. Can you share what makes kinit more secure? – james6125 Apr 05 '18 at 21:12