i've vi'ed some scripts in the past and when i did, my screen froze. i had to go to another terminal and kill the vi process before i was able to get back my screen.
how can i replicate this behavior on purpose? i want be able to do this also if the file or script was doubled clicked, say through the GUI of a File browser.
Hello SkySmart,
How about the usual way by NOT providing the permissions to those to whom you don't want go view the content. Not sure about your UI(either you are having authentication process in it or not).
Thanks,
R. Singh
If they have to be able to read it to execute it for their job, consider writing a calling script that will use sudo to elevate the permissions so they can still do their job when you have locked the real script away from prying eyes.
So, if you have my_script that is sensitive, change the permissions so that they cannot read it and rename it to my_script.protected
Then create a public script that just contains something like this:-
#!/bin/ksh
sudo $0.protected $@
Using $0 means that it should find the protected script down the same way it found your open script. Of course, if you rely on the userid within the script you might have to work around this by determining who is logged on to the terminal. The whoami command might help if that is the case.
I hope that this helps,
Robin
This extremely common question always has the same inescapable conclusion.
Yes, but --
Encryption does not work that way.
But what if --
Encryption does not work that way.
Maybe if it --
Encryption does not work that way.
To prevent people from reading your scripts/passwords, chmod.
To prevent people getting access to something which reads the scripts/passwords, sudo.
To prevent root from getting at it... You're out of luck.
This question fools everyone eventually... I spent a long while earlier this year down a rabbithole trying to find a way to make arbitrary apache suexec secure, until I realized I was fighting what amounts to the same problem -- how to prove identity to the computer without using secrets.
If you don't want anyone viewing your content, an option would be to encrypt the file with a secure passphrase.
On Solaris, use encrypt / decrypt
On Linux, use gpg2
But then they could only run the program if they knew the passphrase - either that, or include the password in the program, which leaves you with the same problem!
His question was to prevent the file being viewed. So I assume the file owner is only user that should have access to it.
I'm not sure what the point of the password is then, if chmod is good enough.
Because if you chmod it, the root user would still be able to access it?
i think i found online solutions for this.
shc and enscryption
shc turns the script into binary. which is really appealing to me. but im reading reports that the content of the script can be easily viewed if someone ran ps -ef or something. on the running script.
i really, really appreciate the help that all the posters in this thread have provided. i really do! im going to thank each and every post.
As I posted last week:
Encryption really, really, really doesn't work that way, no matter how far down the rabbit hole you go.
There are no methods to protect from root, at all.
I am not speaking figuratively.
You are looking for a logical contradiction.
I'm interested to know more.
For instance, if a user encrypts an ascii file using the following method:
# echo hello > hello.out
#
# encrypt -a aes -i hello.out -o hello.out.encrypted
Enter key:
# ls -lrth hello.out hello.out.encrypted
-rw-r----- 1 sysadmin other 6 Mar 28 15:00 hello.out
-rw-r----- 1 sysadmin other 56 Mar 28 15:01 hello.out.encrypted
# file hello.out hello.out.encrypted
hello.out: ascii text
hello.out.encrypted: data
#
When the encrypt program asks the user to insert a key, how can root user capture the input?
I must be missing the point. From the prompt you are showing ( # ), one would assume that root is running this code. Are you saying that root doesn't know the characters that he or she is typing into the terminal after receiving the prompt for a pass phrase from the encrypt utility?
What is it that you are trying to do?
The encrypt program can be run by any user to encrypt their files, its available on Solaris.
The example, I've ran above is under a non-root user.
But Corona688 did say that "There are no methods to protect from root, at all." So I'd like to know how can root user know the encryption key to decrypt a users file.
I'm trying to understand how Corona688 came to that conclusion.
You are talking about two different things. If a file is encrypted, only users who know the pass phrase or who have enough compute power to determine the pass phrase by brute force can read the plain text version of that encrypted file.
The topic of this thread, however, is how can a user encrypt a shell script file and let another user who does not know the pass phrase used to encrypt that script run that script without being able to read it as clear text. And, the answer is that it cannot be done.
If a script is obfuscated by its owner and can be run by somebody else without knowing the obfuscation method used, then anyone who has read access to the file can also read the clear text of that script and/or run the file.
And, if a file is made unreadable just by changing its mode, that will not keep any root user on that system from reading that file (both because root can read any file with any read permission bit set and because root can change the mode of any file to any mode they choose.)
I have assumed that you don't wish to type in a password every time you want to run that script, because 99.9% of the time, people don't.
If the script contains instructions for decrypting itself without a password, root can read it and decrypt it, because it literally contains step by step instructions for doing so.
Root has full control of the machine. They can alter it to their needs. They can do things like subverting your profile, subverting system libraries, altering your environment, setting up full system traces on platforms which support it, and even doing minor alterations to the kernel. They could trace you typing in your password if they really, really want to, or (much more easily) fake you into typing the password into something else.
I won't go into more details, as I'm not in the business of making malicious hacks. But you cannot defend from root.