SUSHC Security

There are currently a number of ways to run programs as another user in LINUX, these include su, sudo, ssh to name a few. Also, for binaries, the "setuid" can be set.

However, there are no easy ways to do this with shell scripts, especially ones called in non-interactive scenarios such as in the "cron" system.

The following ways already exist, but have the associated problems associated with it.

Command Problem
su The problem here is that the password needs always be entered. It is a big hack to make this work in a non-interactive scenario.
sudo This can be set up to do this though navigating your way through "/etc/sudoers" file is a pain, especially as you need to be "root" to edit it.. All in all this is overkill and over-complex for what is required here.
ssh You can use "ssh" with the "authorized_keys" mechanism activated. However, this overgrants permissions as all programs can be run and not just specified shell script.

To fill this gap the "sushc" program was created.

Security Mechanism

One of the reasons why it is difficult to run shell scripts as another user is the many security implications of doing so. System crackers can use such mechanisms to break into systems, or use them to invoke "privilege escalations" should they break in. For this reason the "sushc" program has a strict security mechanism to prevent improper use.

When "sushc" is invoked to run a shell script, it performs certain checks. Imagine you are logged into the machine as "current_user", and you execute the command:

sushc  target_user

It will perform the following routines:

  1. It checks that "" is readable by "target_user".
  2. It checks that "" is owned by "target_user".
  3. It checks that "" cannot be written to by anyone else except "target_user".
  4. It scans the "" file to check that "current_user" has been granted permnission to run it.

If any of the above fail then the program exits with error and the shell script is not run. If all the above passes then:

  1. The sushc program removes various environment that it considers dangerous variables if they are pre-set. A list of these is in The Manual.
  2. The command "/bin/sh" is executed.

Explicit grants

As mentioned in point (4) in the previous section, and in the overview, it is necessary to grant "calling" users permissions in the shell script itself in order for them to be able to run that script as the target user. This is done by adding the line:

sushc -grant  current_user

in the shellscript. This can be in a shell "comment" by prefixing it with a "#" character:

# sushc -grant current_user

It must exist before any other commands occur on the shellscript.

The way it works is that "sushc" will read the script file prior to executing it looking for the "sushc -grant" lines. It will stop when:

  1. it finds a line whose non white-space character is not "#" and where the first word is not "sushc"
  2. it comes across the "sushc -end" line

If the "current_user" has not been "grant"ed permission to run the script then the check fails.

Environment Variables

When all the above checks pass, prior to running the script the "sushc" program removes certain environmen variables that may be considered risky, such as "IFS" and anything beginning with "LD_". A complete list of these are listed on the manual page.

One environment variable it does NOT remove is the PATH one, so when creating a script to be run by "sushc" then it is worth considering setting this in the script itself.