Authentication in Condor

Authentication in Condor is flexible and robust, but it must be properly configured. Authentication allows a server process (not necessarily a process on the central manager) to confirm the identity and therefore validity of a client processes. Fancy forms of authentication are supported by Condor, such as certificate-based SSL authentication and Kerberos, but the basic forms of authentication are local and remote filesystem methods and password-based authentication.

Local filesystem authentication is perhaps the strongest form of username-based authentication when administrative access¹⁾ to a computer is properly limited. It is performed when both the server and client processes are running on the same physical machine. This form of authentication will only be performed if the client's SEC_CLIENT_AUTHENTICATION_METHODS configuration variable and the server's SEC_DEFAULT_AUTHENTICATION_METHODS (or the appropriate SEC_*_AUTHENTICATION_METHODS) both list “FS” and they mutually agree to perform this form of authentication. If so, the client will write a file to the /tmp/ folder. Assuming the client does not have root access²⁾, the file's ownership will be that of the effective user and group IDs. The server process then checks the user and group ownership against the user accounts of the local computer and/or user domain. If the ownership is what the server process expected, the server considers the client authenticated and uses the client's credentials to decide if the client has the proper permissions to have its request fulfilled by the server. The form of the credentials are in the form <username>@<hostname>/<domain>. Thus, if a client process's “<username>@<hostname>/<domain>” is listed in the appropriate ALLOW_* configuration variable (such as ALLOW_READ and ALLOW_WRITE), the client's request is fulfilled by the server.

Remote filesystem authentication is another form of username-based authentication. It is performed if the client's SEC_CLIENT_AUTHENTICATION_METHODS configuration variable and the appropriate SEC_*_AUTHENTICATION_METHODS configuration variable of the server both list “FS_REMOTE”. Like local filesystem authentication, remote filesystem authentication involves the client creating a file in a specific location and the server authorizing the client based on the file's ownership. Unlike local filesystem authentication, the location where such a file is created is not limited to the /tmp/ folder but is in an administrator-specified location, ideally a shared filesystem. Since the location is on a shared filesystem, this allows for greater flexibility of authentication while also posing security concerns that must be addressed. The main reason for using remote filesystem authentication is because the client can be authenticated to the server even if the client and server processes are running on two separate machines. Since a shared filesystem typically the commonality between machines, remote filesystem authentication is the easy yet reasonable way to authenticate processes that are running on separate machines.

Remote filesystem authentication is not foolproof. The security of this type of authentication is directly related to the amount and type of access-control provided by the remote filesystem location and its surrounding infrastructure. For example, if a group of computers share user account information through a Unix home directory service it may be tempting to assume that one username is persistent across all of the computers in the domain. To allow one user access to Condor from any of the computers in the domain, you would tell Condor to allow any client that matches user@*/cs.wlu.edu. This could be problematic if the remote filesystem does not control which computers are allowed to access and modify its files. If any unauthorized computer is allowed to access and modify the files in the shared filesystem, a malicious computer can connect to the shared filesystem and use its local root account to make the file with whatever arbitrary ownership it wants and therefore spoof the server into thinking that the file's owner actually wrote the file instead of a malicious root account writing that file. Thus, authentication would map and allow “user” to login to the computers condor1 as user@condor1/cs.wlu.edu and condor2 as user@condor2/cs.wlu.edu correctly but the asterisk mask of the hostname in user@*/cs.wlu.edu would also allow access to the malicious “user” that authenticated as “user@EVIL_COMPUTER/cs.wlu.edu”. Since the malicious computer could pretend to be any arbitrary username, the malicious computer could effectively gain access to any permission level in the ALLOW_* configuration variables that ends in “@*/cs.wlu.edu”, which would be very bad. In order to avoid all of this, only allow specific computers to access the shared filesystem and don't allow untrusted users to have root access or sudo privileges on those computers. To be more secure, avoid using the asterisk “*” in any of the ALLOW_* configuration variables in order to be as specific as possible when specifying which users and machines are allowed to access any part of Condor.

Password-based authentication is the last form of basic authentication in Condor. It is performed if the client's SEC_CLIENT_AUTHENTICATION_METHODS configuration variable and the appropriate SEC_*_AUTHENTICATION_METHODS configuration variable of the server both list “PASSWORD”. The main difference between the previous two forms of filesystem-based authentication and this form of authentication is that password-based authentication doesn't have the capability to authenticate specific usernames or hostnames. If a client is authenticated to a server with password-based authentication, the server still does not know what specific username the client is running under; all it knows is that the client is running as a user that has access to the password file, assuming the password hasn't gotten into the wrong hands. Instead of authenticating to Condor as <username>@<hostname>/<domain>, clients who authenticate to Condor with password-based authentication are by default mapped as condor_pool@<domain>, where “condor_pool” is literal. In order to grant permissions to a client that authenticated with a password, “condor_pool@<domain>” must be added to the appropriate ALLOW_* configuration variable. Because password authentication maps to condor_pool@<domain>, which doesn't include information about the client's username or hostname, it is not possible to restrict permissions to specific users or machines when a client authenticates with a password. Thus, when Condor uses password authentication, it is assuming that the administrator has sufficiently limited access to the password to a select few trusted users who all will have the same effective permissions in Condor. This is typically accomplished by having the password file owned by the user that the Condor daemons run as (typically root or condor³⁾) with its permissions set to allow read access to that user and no other user so that no one can simply copy the file and use it to maliciously gain access to Condor⁴⁾.