2

I have a set of scripts (bash, ruby, python) and want to put everything into a container like file so I can deploy this container on a lot of servers. This scripts need to protect from accessing other users (root included). So my idea was to create a encrypted container with all the sensitive scripts and mount this into RAM on boottime. But after mounting this container, the files are accessible from the system for everybody which has permission to it.

Is there some technique to deploy interpreted scripts (bash, ruby, ...) onto a system and nobody can see its content at any time? I don't want to run some "obfuscating" scripts.

f00860
  • 515
  • The interpreter that executes the script will be running as the user that executed it and the interpreter will need to open the script file in order to read its contents in. You can't do this with an interpreted language. You might be able to do something with helper executables and setuid/setgid though. – Bratchley May 28 '14 at 13:58
  • Root can't be locked out, either, as the purpose of root is that it's the account that should be able to get you out of any mess you find yourself in. – Bratchley May 28 '14 at 13:59
  • I hoped there are solutions like echo "echo 'Hello World'" | bash or ruby -e "puts 'Hello World'" for a whole script so I don't need the actual file. Are there no proper solution for this kind of problem? – f00860 May 28 '14 at 14:17
  • This isn't usually a problem for most people. Usually if the feature-implementing logic needs credentials different than that of the original user (such as the ability to read a file that contains a script), you would communicate over a Unix socket or dbus from the client utility the user calls to the server that actually performs the operation. That's probably overkill here. The setgid/setuid binary suggestion should work for locking out regular users though and it only involves writing a C program that does a system() call. – Bratchley May 28 '14 at 14:22
  • It is not just the credentials. It is a management software written in different scripting languages which will be deployed on servers which users have root access. This code needs to protected from leaking out into the public. – f00860 May 28 '14 at 14:25
  • Would it be possible to run this partially as a network service? That would be a solution similar to how a lot of distro's deploy system updates (clients that run locally on the users' machines and make calls over the network to a server). Ultimately, if it's on the system, root is going to be able to do it unless you make changes to the capability bounding set which your users aren't going to ever want to do. So if it's on their machine, their root accounts will be able to access it. – Bratchley May 28 '14 at 14:35
  • For shell scripts there is shc. But you should not use it as encryption replacement. "shc's main purpose is to protect your shell scripts from modification or inspection." http://www.datsi.fi.upm.es/~frosal/sources/shc.html – Strubbl Jun 05 '14 at 05:56

2 Answers2

2

It is not possible to make a program unreadable from the user who is executing it. In particular, root can read all files.

What you're asking for makes no sense. You can put your encrypted container on a machine, and its administrator won't be able to read it. But if you want to use content that is located in that container, you need to decrypt that content, and then the administrator can read it.

You can use file permissions to protect files from non-root users. Encryption is not useful for that: encryption is only useful to protect data when someone has access to the medium that contains the data (e.g. to protect data stored on a disk from someone who gains access to the disk, or to protect data in transit from someone who can eavesdrop on the communication channel).

If you don't want people to be able to copy your software, don't give them your software in the first place. You may be able to arrange for the sensitive parts of your software to run on your own servers, and only ship some dumb clients. If you want to limit the number of copies that your customers are running, do it through a legal contract.

0

It depends on what you mean by obfuscating.  Here's an approach that lets you wrap scripts in compilable programs, allowing you to turn them into binary executables.  Write a C program that looks like this:

#include <stdio.h>
#include <stdlib.h>

    ︙

        FILE    *sh;

        sh = popen("/bin/sh", "w");            // Use "/bin/bash" if you need to,
                                               // or whatever interpreter you need.
        if (sh == (FILE *)NULL) {
                perror("popen");
                exit(1);
        }
        /* Embed your script here. */
        fprintf(sh, "for x in red blue green\n");
        fprintf(sh, "do\n");
        fprintf(sh, "        echo x = \"$x\"\n");
        fprintf(sh, "done\n");
        /* End of your script. */
        fclose(sh);

If it’s more than just a few lines, it may be more manageable to store it as a string array. Then compile this program.

  • If you want the program/script to be executable by non-root users, make the binary execute-only (e.g., mode 710 or 711).
  • Of course, root will be able to read the file regardless of its mode.  While the binary executable will appear at first glance to be just a binary executable, it is trivial to extract the text of the script with the strings command.  You can mitigate this a little by adding some lightweight pseudo-encryption of the script text in the C program; e.g., something trivial like XORing each byte with a constant (ideally one with the 0x80 bit set).  This cannot provide real security; since the program must contain the logic to "decrypt" the script, any analyst can do the same thing.  This provides only a little "security through obscurity".

No solution will be foolproof, because (at least for a shell script) users will be able to see what commands are being run by using ps in another window; but that would give them only fragmentary glimpses at the script.

Of course, if the logic of your script is really sensitive, the real answer is to translate it into a compilable language.

(Adapted from Avoiding users to corrupt and use a script.)