Background

With the recent shift towards supporting the development of science gateways on the TeraGrid, there has been much debate over how to properly secure the shared resources (Community Accounts) that these gateways use to interface with RPs on the backend.

At the recent TeraGrid Gateway Security Summit, this debate and several different ideas were boiled down into a couple different security appropaches. These approaches range from not doing anything special to secure these accounts, to requiring that every program the account wishes to run be vetted by a sysadmin and authorization added for the account to run that one particular program.

Because we believe that the latter approach is probably not sustainable, and the former approach fails to provide sufficient accountability for who is doing what with the account, Sean McCreary (NCAR) and I proposed a solution that falls somewhere in the middle.

I call this solution "W^X With Path Restrictions". The basic requirements of this approach are as follows:

• Absolutely no direct login access will be allowed to any computer.
• All work must be submitted through a grid gatekeeper.
• Accounts will only be able to execute programs with specifically approved paths. However, any executable in an approved path may be run.
• Accounts will not be able to execute any program that they could potentially modify.

The reasoning behind these requirements is as follows:

• In addition to being a security risk, login accounts for which the stated intention is to share the credentials between more than one person are a direct violation of Purdue's site security policy. By disallowing direct access and ensuring that all work is accounted for, we basically turn these into generic service accounts instead.
• By limiting the path, we ensure that even in the event of a comprimise, the account can only be used as the gateway developers intended, and cannot execute arbitrary system commands. If the path is set cleverly (for example, to a gateway community software area), we can also determine who is responsible for each program a community account runs simply by looking at the ownership and permissions on that executable.
• By preventing the execution of any program the community account could modify, we prevent the circumvention of any of our previous security measures.
• By only restricting the path and not maintaining a list of individual allowed executables, we make it easier for gateway developers to deploy new applications or modify existing applications without the need for sysadmin assistance.

Implementation

In order to fulfill the above requirements, we have developed the following implementation at Purdue for securing community accounts:

• When a community account is created, we set the login shell on all our systems to the string "nologin". This string was chosen mostly because it has special meaning in our local account management software, which is beyond the scope of this document. However, any invalid login shell (one that does not exist, is not listed in /etc/shells, or does not allow any login access) will work. Setting the shell this way actually provides two safeguards against login access. First, on any system that uses an appropriately configured PAM stack for authentication, login attempts will be denied for any account which does not have a valid login shell listed in /etc/shells. Second, on systems that do not use PAM or where PAM is not configured to make this check, login attempts will fail because the system will not be able to exec the account's shell.
• As with all TeraGrid accounts, we do not return a password to gateway developers for their community account at Purdue. We require that all sessions for these accounts be authenticated with either certificates or SSH keys.
• Because community accounts at Purdue do not have direct login capabilities, we generally don't mind if they modify their own .profile, .ssh, .rhosts, or similar files. Therefore, we place no restrictions on the account's home directory, other than not being able to execute any program stored there, which will be described later.
• We have applied this patch from NCSA to our Globus job manager script. This patch allows the admin to specify an arbitrary command that Globus will run prior to the start of the job to filter commands for community accounts. To use this patch in our approach, we have just changed the value of " FILTER_COMMAND" to our own job validation script.
• We use this script to filter commands for community accounts at Purdue. The script reads in a list of community accounts and authorized paths from a file, and checks the path of the requested executable against the list of authorized paths if the account running the job is a community account. It also checks to make sure that the community account does not have write access or ownership on the requested executable or any of its parent directories. Note that you'll probably have to change the location of "job_perm_file" inside this script to something appropriate for your site. An example job_perm file is provided.
• When a community account is created, we also create a community software area and a developer group with write access to this area. We require all developers to obtain their own individual TeraGrid accounts and use them to upload software for the gateway.

With this approach, we can ensure that the only access a community account has to Purdue systems is the ability to run specific jobs after being authenticated and logged through a grid gatekeeper. By restricting the list of authorized paths to the community software area, we ensure the account can only be used for gateway related purposes and can only run software installed by the developers. It is then expected that the gateway developers will ensure the security of their applications and not allow the account to be used for anything malicious. However, should they fail to meet that expectation, the amount of damage the community account can do is somewhat limited, and it can always be deactivated completely in the event of an incident. Furthermore, this approach gives us some degree of accountability with respect to who is responsible for the software a community account runs and who used the community account to run what jobs at what times.

Caveats

• Take care when setting the allowed paths for the account. It may be possible to escape the restricted environment and run arbitrary commands if the path is set too broadly. If programs from common system locations need to be run, it may be better to add a symlink to those programs from another directory and add that to the path.
• Since this approach does not require every incoming executable to be vetted by a sysadmin, it does not protect against mistakes on the part of the gateway developers. If they write a program that allows the community account to bypass these restrictions, it will not provent this. It may be prudent to ensure the developers are using good security techniques before enabling the community account.

Last Updated: Mon, Nov 8, 2010 10:25    Author: gveldman