Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
I'm sorry in advance if there is a thread similar to my one, but I didn't find it with linuxforums.org site search.
It would sound a bit cheesy but the matter is that I can't find WORKABLE solution to encrypt shell scripts and keep it executable. I've tried SHC, but source code of shell script encrypted with shc can be retrieved easily (execute it and run ps ax). I also found wzshSDK but I don't know how to get it, it seems that it's no longer maintained.
The purpose of encrypting is to close source code of the scripts as they may contain password and other critical data. Encrypted script should be executable just like it's unencrypted one (little slowdowns in execution speed are acceptable).
Any help is highly appreciated. Thank you in advance, mates!
There is a recent thread here that discusses using encryption to protect a shell script. Unfortunately it concludes that this isn't the right approach to protecting a shell script with passwords in it.
The right way to do it is to limit read access to the script to the root user and not allow anyone else to login as root. If the users need to perform actions as root then use sudo to only allow the exact commands they require.
There is a recent thread here that discusses using encryption to protect a shell script. Unfortunately it concludes that this isn't the right approach to protecting a shell script with passwords in it.
The right way to do it is to limit read access to the script to the root user and not allow anyone else to login as root. If the users need to perform actions as root then use sudo to only allow the exact commands they require.
Let us know how you get on,
Chris...
Thank you for your input, Chris.
I have read the thread you suggested but the matter is that the script I would like to encrypt, will be located physically at customer's side. I mean that it would be possible for customer to access that file at a filesystem level (for example by booting Live CD like Knoppix). That's why it doesn't matter which permission I would give to this file.
I have 1500 lines long shell script and I really don't want to rewrite it into any programming language to make it be compiled. But at the same time, the mind that it's the only way is getting closer.
The main idea is to compile the script like SHC does. I even will agree that such a way wouldn't be 100% safe. But SHC's bug is killing me: just run compiled script, run 'ps ax' and you'll see source code of the initial script.
There are several shell scripts obfuscators for Solaris but I didn't cope with any one for Linux. Probably somebody may suggest some?
I really appreciate your help, guys. But I'm stuck on it and unfortunately can't move forward.
I'm afraid I'm going to have to take my default pessimistic stance on this one. You can obfuscate or even produce a compiled app to do what you want, but if the attacker (customers) have root access at their leisure and an interest in recovering the password, then they will get it.
With this in mind it becomes important to have a plan in place for when the customers do get the password. Perhaps responses used then could be applied in advance so it becomes less of a concern if the users get the password from the start.
Can you tell us what the password is protecting? We might be able to suggest some alternate strategies that don't need a password in a script.
Can you tell us what the password is protecting? We might be able to suggest some alternate strategies that don't need a password in a script.
The password is meant to protect system self updating packages. This system is something like a router/firewall/traffic shaper/qos manager/etc which is customly developed. Let me name it as QSET.
From time to time QSET checks availability of new update packages on remote server and if there are some, it fetches them and installs. This packages are encrypted by GPG symmetric algorithm (with password in other words) and every package is applicable only for one QSET. This password is generated on QSET unique ID in some sophisticated way.
The script I'd like to protect, is located at QSET and decrypts update package as well as installs it. To decrypt package, the script generates password based on QSET unique ID (which is known by QSET's owner) and applies it for GPG encrypted package. The way of password generation from QSET ID is to be closed from users. This is a primary task for me at the moment.
Sounds interesting. I have some thoughts on this, but to be properly useful I would like to exactly what the problem you are trying to solve is.
If the customer gets the password then they could decrypt the update outside of the update process, but I'd like to know why that is a problem. Are you trying to stop one customer from applying another customer's update or do you want to hide what is in an update from the customer themselves? Maybe something else entirely.
This may sound like it's wandering off topic, but it affects which alternatives would be useful versus ones that miss the point entirely.
If the customer gets the password then they could decrypt the update outside of the update process, but I'd like to know why that is a problem. Are you trying to stop one customer from applying another customer's update or do you want to hide what is in an update from the customer themselves? Maybe something else entirely.
The main idea is not to show contents of update package as it may contain vital data like source code of QSET components and others.
Another problem is that the passwords for system are being generated from QSET ID and knowing ID of certain QSET it would be possible to get passwords for it. The password generation is performed during the installation only, and if user gets installation script unencrypted he(or she) will know how to get password to another client's QSET by it's ID. Of course IDs aren't shared in any way and ID is only shown at the main page of QSET administration panel after successful login but...
I have an idea how to close password in installation script: every installation script would be prepared for each user personally with arbitrary passwords for QSET. But I still haven't got an idea how to protect updates. Any ideas are very appreciated.
I have an idea how to close password in installation script: every installation script would be prepared for each user personally with arbitrary passwords for QSET.
Good call. As you say, predictable passwords are a bad thing even if nobody knows how to predict them yet.
Quote:
Originally Posted by artiomix
The main idea is not to show contents of update package as it may contain vital data like source code of QSET components and others.
I was afraid you were going to say something like that. Your basic problem is the same problem faced by DRM systems: Encryption only protects information from unintended recipients. Your customer is the intended recipient in the exchange therefore encryption will not be effective protection. Woolly thinking like "actually the DVD player is the intended recipient." is why people still expect encrypted DVDs to be foolproof.
In the first instance I'd rip out the DVD and floppy drives. Lock down the BIOS and only boot from the main HDD. To be really paranoid, use case switches so the system knows when the case has been opened and can refuse to boot at all, then during the tech support call you can tell them they voided the service agreement and offer to sell them a new one.
If that can't be done, then the only measure I can think of that would actually provide reasonably effective protection would be to use a trusted platform module (TPM) in your QSETs. Put all of the update programs on a separate, encrypted partition or disk image that gets mounted at boot time and seal the key with the TPM. That way if they boot with Knoppix or suchlike then they will be unable to unseal the key because of the different boot process. Then you can rely on the normal operating system protections to keep the user away from the unencrypted partition.
Finally, if neither of these options are workable, obfuscate as hard as you can, port your script to a compiled language, precompile the updates, and develop a plan for what to do when the customer does get their hands on the key.
You could chown root, chmod 700, then configure sudo not to require a password to run that specific script from a specific user. This may or may not work for you.
If that can't be done, then the only measure I can think of that would actually provide reasonably effective protection would be to use a trusted platform module (TPM) in your QSETs. Put all of the update programs on a separate, encrypted partition or disk image that gets mounted at boot time and seal the key with the TPM. That way if they boot with Knoppix or suchlike then they will be unable to unseal the key because of the different boot process. Then you can rely on the normal operating system protections to keep the user away from the unencrypted partition.
Finally, if neither of these options are workable, obfuscate as hard as you can, port your script to a compiled language, precompile the updates, and develop a plan for what to do when the customer does get their hands on the key.
Let us know how you get on,
Chris...
Sorry for a delay with getting back here.
Chris, thank you for all your input and time, it's invaluable for me.
Finally, I think that the best way is to move updating system to C programming language. I'll move the component of updating system that decompresses and installs update package.
Unfortunately I can't start doing this right now and hope to proceed with it some time later (there is some new project that should be finished asap). Any way, I'll inform you about the final solution for updating/installing component of QSET by posting here or at my blog: Linux Screw.
Open Source Security Myths Dispelled Dispel the five major myths surrounding Open Source Security and gain the tools necessary to make a truly informed decision for your IT organization subscribe
InformationWeek InformationWeek is the only newsweekly you'll need to stay on top of the latest developments in information technology. subscribe
Redhat / Fedora Linux Help Help and discussion related to Redhat and Fedora Linux.
Submit Your Article
Latest Articles
Article Categories
Join Linux Forums Today
Linear Mode
