hi guys,

i have some shell scripts which has password stored in it (clear text! oh man!). Is there a way that i can encrypt it and yet still be able to execute it?

thanks!

i have some shell scripts which has password stored in it (clear text! oh man!). Is there a way that i can encrypt it and yet still be able to execute it?
In short: no.

First of all you should not store passes in shell scripts unless you are onehundred percent sure there is no workable alternative. Next to that the script needs to be parsed to be executed so after putting in the pass phrase|word it will be decrypted in memory where (shreds of) it could be read anyway. This makes this kind of obfuscation very limited in a true security-enhancing way.

Swakoo, what does the script need a password for? Maybe we can help you alter your implementation so you don't need to put a password in the script. Apart from the security problem, passwords in scripts are a nightmare to maintain!

what do you mean by the script needs to be parsed so as to decrypted password in memory? how do you achieve that?


well.. one thing is my mysql backup script.. I run mysqldump which needs the uid and pwd for the backup user account to initiate backup. But how do I do it such that the password won't be seen in clear text... would encryption (of the shell script) be good?

another one would be... my user actually created a shell script to connect to dB. I would like that script to be encrypted at least...

possible? his arguement is that php scripts (like vbb, and other php apps) store their config (and hence, passwords) in clear text config files...

For a script to run, the commands must be decrypted first. When you run a script, it is read by a bash process which is owned by the user running the script. For that bash process to be able to read the commands in the file, it must be able to de-crypt them... how should it do this - it would need the key to decrypt the script... But where would it get the key from - that would have to be embedded in the script too, which defeats the point. This is the same problem as DRMd media by the way - you have to give the key to the player for it to play the media.

Ah. Not sure about mysql stuff. It would have been so easy if you had wanted to remote login...

It's a problem whenever you want to automate stuff which requires elevated privileges. If you're going to try to implement something which does this, you'll need some sort of guardian process which contains all the keys, and only gives them out to programs it trusts. One approach is to have a program which is a binary and has just execute permission (it can't be a script because they must always have read permissions).

This process would accept requests to connect to the database and execute scripts and so on. It would have some mechanism for deciding what requests were trustworthy and should be executed. For example, it might have a list of known OK scripts which are run regularly, and only run those (using checksums to verify they've not been modified). If you require that scripts from some source should be trusted, you'd have to use some crypto signing to verify the source.

The difficulties with this approach are:

• it adds more overhead (you'd have to add a new signature to the database of known good sources when you add a new script/trusted source)
• it adds load - checking crypto sigs is quite heavy if you have to do it a lot.
• it's complex, and liable to break unless you write bugless code
• it's a possible security risk. If there's a flaw in how it decides to trust things, someone might be able to run stuff they shouldn't without any authentication
• it's probably pointless - ultimately you have to trust someone with some sort of password, whether it's in the form of being able to read a script or having the signing keys...

hmm lots to consider... so i can't just crypt a script and expect it to run...

Nope. Your best bet is probably compile a binary and set the perms so it can't be read, just executed, but that's much more of a pain to update then a script - imaging wanting to change your database password (which you should do every so often) - you'd have to re-build your binary. In a production environment, that means re-testing etc...

so considering i run shell scripts to do backup of dB, what's the best way about it then?

Change the permissions of the scripts as only readable by the user account which does the backups, make sure that user account has a good password. Trust the person who controls that account (and the root of the machine too of course).

If you need more security that that, you might consider implementing some sort of connection agent program as described above, but then you incur the penalty of it being more difficult to maintain. It depends on your situation - how many hoops are you prepared to jump through to protect the database password?

You might consider reading in variables for the password and username variables by sourcing a credentials file.

The credentials file would be in that users home directory and readable only by that user. This approach may allow a script readable/runable by any backup member to read in that users credentials.

This is similar to mounting a cifs share from a script using 'credentials=' instead of username= and password= in the script. However if /proc is readable by normal users, then cat'ing out /proc/<PID>/cmdline could reveal the password if the client doesn't clear it in time. If the script can only be read or run by the user or group, then /proc/<PID>/environ won't be readable by a normal user.

According to the mysql info manual:
The most secure way, according to section 5.9.6 of the mysql info manual, is to run the script with the mysqldump -p option being empty so that it prompts for a password.

You may want to consider running the backup as a cron job. Run by root or a member of the backup group.

Another thing to research is the "Match" and "ForceCommand" options of sshd_config. Using google for the terms "sshd_config mysqldump Match ForceCommand" may reveal articles how to trigger a backup script by logging in with a backup member's credentials.

http://www.linuxsecurity.com/content/view/117920/49/

this should hook you up.

woah many options... ok i will give it a shot thanks!

I didn't know that was possible. It's things like this that give Linux that "yikes... awsome!" factor.

Great! Automatically does what was suggested - make a binary, and an encrypted one to boot. But without having to re-write the functionality. Nice. The question of maintainability still rears it's ugly head, but I can certainly see how this could come in very handy.

Of course, it's only really obfuscation - the key to de-crypt the bulk of the binary must be in there somewhere, else it wouldn't be able to run. So anyone who can read the file could reverse engineer it pretty swiftly to get an unencrypted binary. This is a big game with malware authors now.

Thanks for the link hanzerik

Your Welcome.