Community Accounts - Requirements

NCSA Security R&D
Last Updated: 11/03/2005

Requirements Document

Project: Community Accounts

Community accounts are a means to allow an entire community of users to access a shared, computational resource without requiring individual accounts for each user. In particular, they can allow a portal application to deal with individual user authentication and then serve as a proxy, accessing shared resources using a community credential and passing data back and forth between the user and the resource. It may also be possible to provide users with limited, direct access to resources in a controlled manner.

Von Welch <vwelch@ncsa.uiuc.edu> Project Manager

Kevin Price <kjprice@ncsa.uiuc.edu> Designer; Programmer

GridChem: The GridChem project aims to develop a computational chemistry grid that allows researchers to access a variety of computational resources without requesting specific access to each resource. This goal is realized using community accounts and a proxy server that handles traffic between the end user and the computational resource.
NCSA Security: The NCSA Persistent Infrastructure Security Group is interested in seeing that community account implementation complies with all NCSA security guidelines and practices.

The following requirements are listed using the 'MUST', 'SHOULD', 'MAY' format. Following each requirement is an indication of which end user(s) desire this feature.

Community accounts MUST be accessed securely using some form of authentication credential [GridChem, NCSA Security]
Utilities MUST be developed that community administrators can use to manage and maintain certificates and other community credentials for resources. [GridChem]
Guidelines SHOULD be developed describing the resource needs of a community account and how they vary from a traditional single-user account.
Utilities MUST be developed that generate a fresh community account on a variety of platforms, and guidelines MUST exist detailing how to generate a community account on a new platform. [GridChem]
Data and job information pertinent to a given researcher MUST NOT be accessible by any other researcher in the community [GridChem]
The credential used by a portal application to a community account MUST NOT be released to the end user or general public [NCSA Security]
Utilities MAY be developed for granting specific users direct access to resources in a limited and controlled fashion [GridChem]
Community accounts MAY be limited in their operation to a specific subset of commands available to a normal user [NCSA Security]
Utilities MUST be developed that allow community administrators access to directly modify community account settings [GridChem]
Resource administrators MUST have contact information for the community administrators, and SHOULD have contact information available for all potential users of the community account [GridChem, NCSA Security]
Utilities SHOULD be developed that can enable auditing of resource usage at the job level, the user level, and the group level.
A means of tagging which jobs are being performed by which users MUST exist; this information MUST also be logged, and the resource administrators MUST have access to these logs [GridChem, NCSA Security]
A means of data access MUST be implemented that allows users to access only their data, and not that of another user [GridChem]
Long-term data storage solutions MAY be implemented with a community account, but they MUST be accessible only through a means that limits access to only those files stored by a given user [GridChem]

The following technologies are possible candidates for implementing part of this project. Each technology is summarized below, along with some notes describing how it might be useful.

UNIX chroot "jails"

The UNIX chroot function present in most UNIX systems allows an application with root privileges to modify the root level of the file system. If the application then removes its root privileges, and the new root file system does not contain any applications with root-level privileges, it should be impossible for the application to compromise the system or write data outside of this new root file system. This function, integrated into the shell of a community account, could be used to severely restrict the access of that account. With proper management, each community account authentication could invoke an application that would generate a "fresh slate" region with just the utilities required, and perform the requested command within this secured area.

UNIX restricted shells

A variety of UNIX shells exist (Iron Bars Shell, fush, rssh) exist that put restrictions on what commands a user can execute. Often, these shells also log all user activity. The drawback to these solutions is that if the user can manage to spawn a conventional shell (sometimes possible through other applications), the user can circumvent any security measures imposed by the restricted shell One such shell could be part of the community account implementation, possibly in conjunction with another technology (such as chroot) to ensure maximum security. The logging capabilities of such shells would be of great benefit in the case of a malicious user attempting to break into or crash the system.

SDSC Storage Resource Broker (SRB)

"The SDSC Storage Resource Broker (SRB) is client-server middleware that provides a uniform interface for connecting to heterogeneous data resources over a network and accessing replicated data sets. SRB, in conjunction with the Metadata Catalog (MCAT), provides a way to access data sets and resources based on their attributes and/or logical names rather than their names or physical locations." (http://www.sdsc.edu/srb/) The SRB may be usable as a means of storing the output from jobs in such a way that only the user who executed the job can access that output. The possibilities exists to either have an SRB implementation with a mirrored user set, have our implementation use an SRB user set directly, or have the SRB user set manipulated as necessary to grant a given user access to a given file.