Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | Last revisionBoth sides next revision |
| condor:administration:authentication [2011/08/09 15:36] – garrettheath4 | condor:administration:authentication [2011/08/09 15:50] – garrettheath4 |
|---|
| 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. | 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** FIXME | **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. |
| Unix home directory service | |
| | |
| Password authentication in Condor has its downsides. | |
| |
