Securing Science Gateways Steven R. Brandt, Rion Dooley, Golden G. Richard III Abstract—Gateways provide access to computational codes as a service to their users. One popular design pattern is to use a single user account on an HPC system to run all workloads for the gateway’s user community. This introduces several security concerns for the owner of the user account, the machine, and the integrity of the workloads run by the gateway. In this paper we present preliminary work on pieshell, a limited, secure Linux shell that runs in user space. We begin by discussing the use case pieshell addresses. Next we discuss how it fills a gap in the existing secure shell landscape. We then describe pieshell’s design and usage within a gateway context before concluding with areas of future work. I. I NTRODUCTION One form of Science Gateway is a system that allows a scientific modeling code to run on a high performance compute (HPC) resource through a shared “community” account. The concept is to allow a large number of people to explore the possible outputs of a model, but without conferring a large degree of trust. The Agave [1], Airvata [2], and Tapis [3] frameworks provide a kind of scientific middleware, a RESTful JSON API to facilitate creation of gateways that fit the above model. While they are far from the only tools in this space, the security issues faced by a person deploying an application using this framework are common. Typically, these tools connect to a compute resource via ssh and run commands through bash. If correctly configured, these tools grant limited access to users, usually the ability to run a single type of calculation. Unsurprisingly, it is possible to inadvertently create security loopholes through misconfigura- tion, so it is important to carefully read the documentation for the framework you are using and spend time thinking about what issues might exist. The authors and maintainers of these gateway frameworks take great care to keep their systems secure. Prior efforts by XSEDE and the SGCI have produced guidelines with best practices for securing a community user account for use by a gateway [4]. However, despite the best efforts of gateway personnel, security breaches are bound to occur. It therefore makes sense to limit the access of each actor involved in running the gateway application code. We also note that there are far fewer resources for self- service application publishers, and it is likely a matter of time until an account on one or more servers become compromised. For this reason, it is desirable to limit the access a gateway user has to commands within a bash environment in much in the way ‘sudo’ restricts access to root commands. This paper Presented at Gateways 2022, San Diego, USA, October 18–20, 2022. https://zenodo.org/communities/gateways2022/ describes preliminary work on pieshell, a restricted Linux shell, written in Python, that runs in user space. II. MOTIVATION Many solutions exist to restrict and/or secure runtime en- vironments. Gateways commonly use OCI [5]-compliant con- tainer runtimes (Docker, runc, crun, runv, etc) to encapsulate an application, then further restrict the container’s permissions through the use of AppArmor, seccomp, or SELinux [6]. In this paper we focus on HPC environments, which tend not to natively support OCI container runtimes due to the privilege escalation required to start a container [7]. Singularity contain- ers are popular with HPC operators due to their enforcement of user space restrictions [8]. This, however, requires Singularity to be installed and available to the shared user account. Restricted shells exist in Bash, Zsh, Fish, and others [9], but require per-account configuration and prohibit behaviors that are necessary, such as changing directory and redirecting output. The Community Shell application (commsh) is another take on a restricted shell focused on gateway use cases [10]. It provides a flexible DSL to whitelist allowed commands, and a plugin architecture allowing callouts to perform custom audit activity. This lends itself particularly well to scenarios where a single user account is being used to perform actions on behalf of one or more unknown external principals [11]. It is, in fact, very similar to pieshell, both in its purpose and implementation. We believe, however, that pieshell has a number of advantages. We list them below. Despite the utility of commsh, and the increased security restricted shells in general provide, they have yet to gain broad adoption within the gateway community. Anecdotal evidence points to the lack of administrative control the gateways have to install and configure the desired behavior over the HPC resources as one prominent reason. However, a full discussion of this topic is beyond the scope of this paper. III. DESCRIPTION In this paper, we introduce pieshell [12], an implemen- tation of the shell in Python. pieshell is implemented as an executable module. It can be invoked in its vanilla form as a pass through shell, or imported as a module and extended by overriding the Python functions listed in Table 1. In our experiments, pieshell is invoked through the command= mechanism provided by ssh’s authorized_keys file (note that it is not necessary to install it as a default shell for any account). This allows us to limit the restricted shell interface to those users logging in via specific ssh keys. Gateway maintainers will still have full and regular bash access.