Restrict editing of Shell scripts

lwasserm · 10-04-2008, 11:48 PM

If you set the scripts to be owned and only writeable by root, other users will not be able to modify them. Why does it matter if they can read them or not? I find it ironic that you would want to keep a user from reading a shell script on an open source OS.

gnashley · 10-05-2008, 01:08 AM

This probably won't help, but maybe worth looking at:
http://comp.eonworks.com/scripts/obf...-20011012.html

David the H. · 10-05-2008, 01:17 AM

Would this work? Keep the "secret" scripts on a restricted filesystem and set with execute permissions only. Then only give the users a wrapper script that calls up the main scripts when run. That way they can't see anything about the real script except the name and location, and messing with the wrapper is unlikely to do anything except break it.

Although I also agree with the above comments. What's so important about keeping the contents of a script secret? I doubt highly that there's anything in there that can't also be learned through other means. It's not like Linux administration techniques are classified information or anything.

Mr. C. · 10-05-2008, 02:37 AM

Quote:

Originally Posted by David the H.

Would this work? Keep the "secret" scripts on a restricted filesystem and set with execute permissions only. Then only give the users a wrapper script that calls up the main scripts when run. That way they can't see anything about the real script except the name and location, and messing with the wrapper is unlikely to do anything except break it.

The fly in the ointment is that execute-only permissions means no read permission. No read permission means the kernel won't open the script to read the contents for execution.

Code:

$ ls -l foo.sh
-rwxr-xr-x 1 root root 29 Oct  5 00:32 foo.sh
$ ./foo.sh
I'm alive

$ chmod a-r foo.sh
$ ls -l foo.sh
--wx--x--x 1 root root 29 Oct  5 00:32 foo.sh
$ ./foo.sh
./foo.sh: ./foo.sh: Permission denied

It doesn't matter if it is called directly by you, the user, or via another program. A script is nothing more than commands for a named interpreter opened as STDIN for the interpreter by the kernel upon execution. The command file (script) must be readable.

jschiwal · 10-05-2008, 02:51 AM

Are the other admin users on the same machine? Is it your password that you are trying to protect. If so, consider using sudo to control what they can execute instead of giving them root access. Otherwise, I don't see what the problem is with administrators being able to read scripts. They might improve on them. Also, why should an admin rely on blind trust that the scripts don't contain errors or do something malicious. If they can't be trusted, why do they have root access in the first place?

WorldIsNotFair · 10-05-2008, 02:56 AM

i have tried the program (shc),

it convert the script to binary, in other way, user can't read this but still have read + execute permission.

so it can be solved with this program.

be positive & take the benefit.

ta0kira · 10-05-2008, 03:02 AM

I really don't think there's a need to question why it shouldn't be read. There are plenty of possible legitimate reasons and OP shouldn't need to explain that.

I think sudo is a reasonable option, though not very maintainable if you plan to incorporate various scripts of the same sort. If you plan to do this with many scripts indefinitely, I'd look into making some sort of remote access system (like I mentioned before with a client/server system) and just have an initiation script on the remote machine that requests the server perform one of the actions. This would allow you to update the actions available just on the server; the initiation script would never have to be changed.
ta0kira

Mr. C. · 10-05-2008, 03:13 AM

It is often necessary to ask the why because questions often incorrectly suggest solutions rather than clearly focusing on and stating problems. For example, in this case, the perceived problem may have been "how do I prevent others from seeing my embedded passwords?", so the proposed solution-question is "how do I make my script unreadable, but still executable". In this example, a better question would have been "how do I securely setup command X to be run by non-privileged users?" Without asking the why, respondents blindly suggest solutions that may not be optimal or correct.

I do agree that there is too much challenging of other people's intentions.

Mr. C. · 10-05-2008, 03:17 AM

Re: shc

Quote:

In the October 2005 Linux Journal, Nalneesh Guar reports that he was able to break the encryption very easily. The man page seems to agree:

You can use it if you wish to distribute your scripts
but don't want them to be easily readable by other people.

Not quite what one would call robust security.

chrism01 · 10-05-2008, 07:41 PM

I agree it sounds like a typical sudo solution. If the other users are in fact sysadmins (ie with root access) its a pointless exercise.

arunabh_biswas · 10-10-2008, 04:03 AM

Quote:

Originally Posted by kirtimaan_bkn

I see this as a genuine requirement. Someone wrote a shell script which do something related to system administration. He need to give that to some one else for the purpose of execution. Now he don't want to share the 'code' (or secret, how he achieved to do that task with shell script) and thats why he want to restrict others to view or modify the script, but at the same time allow them to execute the script.

So in my view, it shouldn't be consider as either 'attempt to either spread malicious software' or 'bad scripts'.

Thanks Kirtimaan,

Kirtimaan Explains the whole issue in just 6 lines...

I hope now I'll get a proper solution in one go.

AnanthaP · 10-10-2008, 07:37 AM

Proper solution is not to use shell scripts.

While I dont believe that a person who has subordinates, really owns the shell script code (as opposed to his company owning it), I agree, it could be a genuine concern to be sure that the correct shell script is running.

So, I would suggest a simple C program that acts like a script controller. something like:

{
while not over
returnvalue=system("command1 ...") ;
while not over
returnvalue=system("command1 ...") ;
while not over
returnvalue=system("command1 ...") ;
while not over
returnvalue=system("command1 ...") ;
..
..
system("commandlast ...") ;
}

may do.

End

Mr. C. · 10-10-2008, 02:52 PM

And what prevents a user from running strace on that stealthy C solution you provide?

Let's be clear - if the code can be executed, it can be read and understood.

ciden · 10-11-2008, 02:59 AM

I guess OP just does not want to share his source code. Nothing wrong with that. Open source is an option not a compulsion.

unSpawn · 10-11-2008, 05:12 AM

Quote:

Originally Posted by ciden

I guess OP just does not want to share his source code. Nothing wrong with that. Open source is an option not a compulsion.

I think you should be careful with posting just "drive by" statements. Possibly you haven't read the thread well enough? The OP was asked for the reasons why and stated that

Quote:

Originally Posted by arunabh_biswas

These scripts contains root previledged commands and I suspect that it might be used by other users or can be manipulate the scripts.

so this has nothing to do with OSS but with access restrictions. Obfuscation and Shc-like encryption are weak "solutions", this question has been asked (not that frequently but perfectly searchable in LQ) and the default answer for allowing unprivileged users access still is Sudo as stated before in this thread.