Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
| condor:administration:authentication [2011/08/09 13:37] – garrettheath4 | condor:administration:authentication [2011/08/09 15:50] – garrettheath4 |
|---|
| **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((In Unix, the ''root'' administrative account is able to change the ownership and permissions of any file in the system. Thus, this form of authentication can be spoofed if a malicious client process has ''root'' access (God forbid!) since it would simply need to create the file and change its ownership to be whatever the server process expects.)), 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, the client's request is fulfilled by the server. | **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((In Unix, the ''root'' administrative account is able to change the ownership and permissions of any file in the system. Thus, this form of authentication can be spoofed if a malicious client process has ''root'' access (God forbid!) since it would simply need to create the file and change its ownership to be whatever the server process expects.)), 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, the client's request is fulfilled by the server. |
| |
| **Remote filesystem authentication** is another form of username-based authentication. 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. 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 is the usual commonality between machines, remote filesystem authentication is the reasonable way to authenticate processes that are running on separate machines. | **Remote filesystem authentication** is another form of username-based authentication. 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. |
| |
| **Password-based authentication** FIXME | 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. The main difference between the previous two forms of filesystem-based authentication and password-based authentication is that password-based authentication doesn't authenticate specific usernames. 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 has access to the password file, assuming the password hasn't gotten into the wrong hands. |
| |
| Password authentication in Condor has its downsides. | |
