Hiding sensitive information in files from user but not from shell scripts in linux

Question

Consider a scenario where a user will be given a tool and the only operation user should be allowed to run the main script. Now tool uses some files to store sensitive information. What I want is that script should be able to access the data in the file but the user should not. The only access he should have is to run the script.

For a simple case lets consider the tool contains 2 files main.sh as the script user can just run only not even read it and info_file which contains some sensitive information only that main.sh should be use that not the user.

This tool may be passed to different users on different machines.What are different ways of handling these kind of scenarios in linux.

Answer 1

One way using SUID.

1. Give only execute permission for group and others on the shell script and info file.

2. Write a wrapper C program to invoke the shell script.

3. Set the SUID bit on the C executable.(chmod u+s file)

   The end user will be invoking the C executable.

Answer 2

A simple option is to encrypt/decrypt a secondary file. The ways to do so explored here - https://serverfault.com/questions/489140/what-is-a-good-solution-to-encrypt-some-files-in-unix

Note that by reading the script it could be easy to retrieve the key and learn the encryption method used unless the script it self is actually compiled code, granted even then it's not invincible since it could be decompiled. If it is compiled language code, most languages have a way to invoke encryption/decryption scripts and you could store just the encrypted version of the storage.

Answer 3

One way, possibly the only way, to protect the sensitive information is to NOT allow users to have ANY direct access to it, either on their own personal machines or on a central server.

For example:

• write an execute-only (i.e. no read access) wrapper script that provides the ONLY way to access the sensitive info, when run with sudo. This does not have to be run as root, a dedicated non-root user is adequate.
• Do not give copies of the script to users for them to run on their own machines. Instead, require them to run it on your server (e.g. via ssh servername sudo myscript.sh), because that is the only location where you have any chance of maintaining access control.