This section describes various aspects of security within Condor.
On a Unix system, UIDs (User IDentification numbers) form part of an operating system's tools for maintaining access control. Each executing program has a UID, a unique identifier of a user executing the program. This is also called the real UID. A common situation has one user executing the program owned by another user. Many system commands work this way, with a user (corresponding to a person) executing a program belonging to (owned by) root. Since the program may require privileges that root has which the user does not have, a special bit in the program's protection specification (a setuid bit) allows the program to run with the UID of the program's owner, instead of the user that executes the program. This UID of the program's owner is called an effective UID.
Condor works most smoothly when its daemons run as root. The daemons then have the ability to switch their effective UIDs at will. When the daemons run as root, they normally leave their effective UID and GID (Group IDentification) to be those of user and group condor. This allows access to the log files without changing the ownership of the log files. It also allows access to these files when the user condor's home directory resides on an NFS server. root can not normally access NFS files.
On a machine where a job is submitted, the condor_ schedd daemon changes its effective UID to root such that it has the capability to start up a condor_ shadow daemon for the job. Before a condor_ shadow daemon is created, the condor_ schedd daemon switches back to root, so that it can start up the condor_ shadow daemon with the (real) UID of the user who submitted the job. Since the condor_ shadow runs as the owner of the job, all remote system calls are performed under the owner's UID and GID. This ensures that as the job executes, it can access only files that its owner could access if the job were running locally, without Condor. On the machine where the job executes, the job runs as user nobody, to help ensure that the job cannot access local resources or do harm.
Condor can also function on all platforms by starting up as user condor. Since user condor does not have the ability to switch UID or GID, all daemons run with both the UID and GID belonging to user condor. The condor_ shadow daemon and the job's executable also run as user condor. This has the effect that the job can access only the files and directories that are accessible to the user condor on the machine where the job was submitted. Owners of jobs must make their input readable to the user condor. A job's output must be placed in a directory that is writable by the user condor as well. In practice, this means creating world-writable directories for output from Condor jobs. This creates a potential security risk, in that any user on the machine where the job is submitted can alter the data, remove it, or do other undesirable things. It is acceptable in an environment where users can trust other users.
On platforms where root access is not needed, Condor can even function without a UID or GID of the user condor. A directory to act as the condor home directory is still required, containing the configuration files, spool, execute and log directories. This home directory is not technically the home directory of any user. In this case, a user condor may or may not even exist, but the directory is still referred to as the condor home directory. If the user condor does not exist, use the CONDOR_CONFIG environment variable such that all Condor daemons and tools can find their configuration file (which in turn defines the locations of other needed files and directories), or place a configuration file in /etc/condor/condor_config. The Condor daemons can then be started up by whatever UID and GID has access to the local condor directory. Normally, users without root access who wish to use Condor on their machines create a condor home directory somewhere within their own accounts and start up the daemons (to run with the UID of the user). As in the case where the daemons run as user condor, there is no ability to switch UIDs or GIDs. The daemons run as the UID and GID of the user who started them. On a machine where jobs are submitted, the condor_ shadow daemons all run as this same user. However, if other users on the machine are using Condor in this environment, the condor_ shadow daemons for these other users' jobs execute with the UID of the user who started the daemons. This is a security risk, since the Condor job of the other user has access to all the files and directories of the user who started the daemons. Some installations have this level of trust, but others do not. Where this level of trust does not exist, it is best to set up a condor account and group, or to have each user start up their own Personal Condor submit installation.
When a machine is an execution site for a Condor job, the Condor job executes with the UID of the user who started the condor_ startd daemon. This is also potentially a security risk, which is why we do not recommend starting up the execution site daemons as a regular user. Use either root or a user (such as the user condor) that exists only to run Condor jobs.
Any executing process has a notion of its current working directory (cwd), the directory that acts as the base for all file system access. There are two sides to any Condor job: the submit side and the execution side. This implies that there are two cwds. On the submit side, the owner's cwd sets a default cwd as a job is submitted. The cwd can be changed with a command in the submit description file. Since many jobs can be submitted at the same time, the commands are flexible in order to set the cwd individually for each job if desired. This submit side cwd remains for the entire life of a job. The submit side cwd is also used as the cwd of the condor_ shadow daemon. Since file system access for the job goes through the condor_ shadow daemon, all accesses behave as if they were executing without Condor.
There is also a cwd associated with the Condor job on the execution machine. It is set to the execute subdirectory of Condor's home directory. This directory is world-writable, since a Condor job usually runs as user nobody. Normally, the executable would never access this directory, since all I/O system calls are passed back to the condor_ shadow daemon on the submit machine. However, in the event that the job that creates a core dump, the cwd on the execute machine needs to be accessible by the job so that it can write the core file. The core file is moved back to the submit machine, and the condor_ shadow daemon is informed. The condor_ shadow daemon sends e-mail to the job owner announcing the crash and providing a pointer to the core file, then residing in the submit side cwd.
While we strongly recommend starting up the Condor daemons as root, we understand that it is not always possible to do so. The main problems appear if you have one Condor installation shared by many users on a single machine, or if you are setting up machines to only execute Condor jobs. If you are setting up a submit-only installation for a single user, then there is no need for (or benefit from) running as root.
What follows are the effects on the various parts of Condor of running both with and without root access.
In addition, some system information cannot be obtained without root access on some platforms (such as load average on IRIX). As a result, when running without root access, the condor_ startd has to call other programs (for example, ``uptime'') to get this information. This is much less efficient than getting the information directly from the kernel (which is what we do if we're running as root). On Linux and Solaris, we can get this information directly without root access, so this is not a concern on those platforms.
If you can't have all of Condor running as root, at least consider whether you can install the condor_ startd as setuid root. That would solve both of these problems. If you can't do that, you could also install it as a setgid sys or kmem program (depending on whatever group has read access to /dev/kmem on your system) and that would at least solve the system information problem.
You might consider installing condor_ submit as a setgid condor program so that at least the stdout, stderr and UserLog files get created with the right permissions. If condor_ submit is a setgid program, it will automatically set it's umask to 002, so that creates group-writable files. This way, the simple case of a job that just writes to stdout and stderr will work. If users have programs that open their own files, they'll have to know to set the right permissions on the directories they submit from.
Condor provides support for strong authentication, encryption, integrity assurance, as well as authorization. Most of these security features are not visible to the user (one who submits jobs). They are enabled by site administrators through the use of configuration macros. This section describes the authentication, encryption, integrity assurance, as well as authorization configuration macros provided by Condor.
Authentication provides an assurance of the identity of one of the communicating parties. Mutual authentication provides an assurance of the identities of both of the communicating parties. Encoding information such that its contents is not easily decipherable by outsiders is called encryption. The integrity of a message is assured when any form of tampering with the message can be detected. With integrity support, nothing in the message can be added, deleted, or modified without being detected.
When Condor is installed, default configuration settings use no authentication, encryption, or integrity checks, nor are authorization checks provided. This allows newer versions of Condor with security features to work or interact with previous versions without security support. An administrator must modify the configuration settings to enable the security features.
Inside Condor, daemons need to communicate with each other; furthermore, various tools provided by Condor may also require communication with Condor daemons. All these communications can be made more secure through the proper usage of authentication, encryption, and integrity checks. Authorization can be used to protect resources in a Condor pool.
When a daemon receives a request, it uses the client's security configuration information together with its own configuration settings to decide upon the security aspects of the communication. This can be considered a negotiation between the client and the daemon. The daemon replies to the client with a set of reconciled policies that controls the communication, including authentication, encryption, and integrity algorithms.
If the daemon determines that authentication is required, then the client must follow the chosen authentication protocol. After the required authentication, the client can send its request to the daemon. The daemon identifies the access level required for the specific request, and it checks the configuration settings to determine if the client has the required access level. If the client has the required access level, permission is granted, and the request is serviced.
The configuration macro names follow a pattern. Each of the names starts with the string SEC_. This string is followed by a string that describes an access level. The levels are
DEFAULT
READ
WRITE
ADMIN
IMMEDIATE_FAMILY
CONFIG
OWNER
NEGOTIATOR
CLIENT
Both DEFAULT and CLIENT
from this list are not access levels.
The DEFAULT is used to define all levels of access
for a specific configuration variable when individual levels
are not specified.
The CLIENT is used to define the client's requirements
and preferences in a secure communication.
Still within the name of a configuration macro, the access level is followed by another underscore character and then a string describing the communication type. The communication types are
AUTHENTICATION
ENCRYPTION
INTEGRITY
NEGOTIATION
Two examples of the complete macro names are
SEC_ADMIN_AUTHENTICATION
and
SEC_DEFAULT_INTEGRITY.
Each configuration variable would be defined with one of four predefined values. The values are
REQUIRED
PREFERRED
OPTIONAL
NEVER
For example, a line in a daemon's configuration file
to require all interactions to be encrypted is
SEC_DEFAULT_ENCRYPTION = REQUIRED
A second example from a configuration file specifies that all
requests (from a client) that would require a WRITE
access level be authenticated is
SEC_WRITE_AUTHENTICATION = REQUIRED
A daemon uses both the client's security configuration together with its own configuration to choose the communication setting for authentication, encryption, or integrity check. The following table defines whether or not (Yes or No) a communication setting will be used, or if the setting cannot work (Fail) due to a mismatch in the configuration settings.
client daemon Yes/No/Fail
REQUIRED REQUIRED Yes
REQUIRED PREFERRED Yes
REQUIRED OPTIONAL Yes
REQUIRED NEVER Fail
PREFERRED REQUIRED Yes
PREFERRED PREFERRED Yes
PREFERRED OPTIONAL Yes
PREFERRED NEVER No
OPTIONAL REQUIRED Yes
OPTIONAL PREFERRED Yes
OPTIONAL OPTIONAL No
OPTIONAL NEVER No
NEVER REQUIRED Fail
NEVER PREFERRED No
NEVER OPTIONAL No
NEVER NEVER No
The client uses one of two macros to configure authentication:
SEC_DEFAULT_AUTHENTICATION
SEC_CLIENT_AUTHENTICATION
For the daemon, there are eight macros to configure authentication:
SEC_DEFAULT_AUTHENTICATION
SEC_READ_AUTHENTICATION
SEC_WRITE_AUTHENTICATION
SEC_ADMIN_AUTHENTICATION
SEC_IMMEDIATE_FAMILY_AUTHENTICATION
SEC_CONFIG_AUTHENTICATION
SEC_OWNER_AUTHENTICATION
SEC_NEGOTIATOR_AUTHENTICATION
As an example, the macro defined in the configuration file for a daemon as
SEC_WRITE_AUTHENTICATION = REQUIREDsignifies that the daemon must authenticate the client for any communication that requires the WRITE access level. If the daemon's configuration contains
SEC_DEFAULT_AUTHENTICATION = REQUIREDand does not contain any other security configuration for
AUTHENTICATION, then this default defines the daemon's needs
for authentication over all access levels.
Where a specific macro is present, its value takes
precedence over any default given.
If authentication is to be done, then the communicating parties must negotiate a mutually acceptable method of authentication to be used. A list of acceptable methods may be provided by the client, using the macros
SEC_DEFAULT_AUTHENTICATION_METHODS
SEC_CLIENT_AUTHENTICATION_METHODS
A list of acceptable methods may be provided by the daemon, using the
macros
SEC_DEFAULT_AUTHENTICATION_METHODS
SEC_READ_AUTHENTICATION_METHODS
SEC_WRITE_AUTHENTICATION_METHODS
SEC_ADMIN_AUTHENTICATION_METHODS
SEC_IMMEDIATE_FAMILY_AUTHENTICATION_METHODS
SEC_CONFIG_AUTHENTICATION_METHODS
SEC_OWNER_AUTHENTICATION_METHODS
SEC_NEGOTIATOR_AUTHENTICATION_METHODS
The methods are
given as a comma-separated list of acceptable values.
These variables list the authentication methods that are available
to be used.
The ordering of the list gives preference;
the first item in the list indicates the highest preference.
The values will be
KERBEROS
FS
CLAIMTOBE
ANONYMOUS
NTSSPI
As an example, the macro
SEC_DEFAULT_AUTHENTICATION_METHODS = KERBEROS, NTSSPIindicates that either Kerberos or Windows authentication may be used, but Kerberos is preferred over Windows.
The client uses one of two macros to enable or disable encryption:
SEC_DEFAULT_ENCRYPTION
SEC_CLIENT_ENCRYPTION
For the daemon, there are eight macros to enable or disable encryption:
SEC_DEFAULT_ENCRYPTION
SEC_READ_ENCRYPTION
SEC_WRITE_ENCRYPTION
SEC_ADMIN_ENCRYPTION
SEC_IMMEDIATE_FAMILY_ENCRYPTION
SEC_CONFIG_ENCRYPTION
SEC_OWNER_ENCRYPTION
SEC_NEGOTIATOR_ENCRYPTION
As an example, the macro defined in the configuration file for a daemon as
SEC_IMMEDIATE_FAMILY_ENCRYPTION = REQUIREDsignifies that any daemon to daemon communication must be encrypted. If a daemon's configuration contains
SEC_DEFAULT_ENCRYPTION = REQUIREDand does not contain any other security configuration for ENCRYPTION, then this default defines the daemon's needs for encryption over all access levels. Where a specific macro is present, its value takes precedence over any default given.
If encryption is to be done, then the communicating parties must find (negotiate) a mutually acceptable method of encryption to be used. A list of acceptable methods may be provided by the client, using the macros
SEC_DEFAULT_CRYPTO_METHODS
SEC_CLIENT_CRYPTO_METHODS
A list of acceptable methods may be provided by the daemon, using the
macros
SEC_DEFAULT_CRYPTO_METHODS
SEC_READ_CRYPTO_METHODS
SEC_WRITE_CRYPTO_METHODS
SEC_ADMIN_CRYPTO_METHODS
SEC_IMMEDIATE_FAMILY_CRYPTO_METHODS
SEC_CONFIG_CRYPTO_METHODS
SEC_OWNER_CRYPTO_METHODS
SEC_NEGOTIATOR_CRYPTO_METHODS
The methods are given as a comma-separated list of acceptable values. These variables list the encryption methods that are available to be used. The ordering of the list gives preference; the first item in the list indicates the highest preference. Possible values are
3DES
BLOWFISH
An integrity check assures that the messages between communicating parties have not been tampered with. Any change, such as addition, modification, or deletion can be detected. Through configuration macros, both the client and the daemon can specify whether an integrity check is required of further communication.
The client uses one of two macros to enable or disable an integrity check:
SEC_DEFAULT_INTEGRITY
SEC_CLIENT_INTEGRITY
For the daemon, there are eight macros to enable or disable an integrity check:
SEC_DEFAULT_INTEGRITY
SEC_READ_INTEGRITY
SEC_WRITE_INTEGRITY
SEC_ADMIN_INTEGRITY
SEC_IMMEDIATE_FAMILY_INTEGRITY
SEC_CONFIG_INTEGRITY
SEC_OWNER_INTEGRITY
SEC_NEGOTIATOR_INTEGRITY
As an example, the macro defined in the configuration file for a daemon as
SEC_IMMEDIATE_FAMILY_INTEGRITY = REQUIREDsignifies that any daemon to daemon communication must have its integrity assured. If a daemon's configuration contains
SEC_DEFAULT_INTEGRITY = REQUIREDand does not contain any other security configuration for
INTEGRITY, then this default defines the daemon's needs
for integrity checks over all access levels.
Where a specific macro is present, its value takes
precedence over any default given.
There is currently only one method used for integrity checking: a signed MD5 checksum. Its use is implied whenever integrity checks occur. If more methods are implemented, then there will be further macros to allow both the client and the daemon to specify which methods are acceptable.
A configuration file is provided when Condor is installed. No security features are enabled within the configuration as distributed. Included as comments within the configuration file is an example suggesting settings that enable security features. Here is that example of the daemon-side portion.
SEC_DEFAULT_AUTHENTICATION=REQUIRED SEC_DEFAULT_ENCRYPTION=REQUIRED SEC_DEFAULT_INTEGRITY=REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = FS, KERBEROS SEC_DEFAULT_CRYPTO_METHODS = 3DES, BLOWFISH
This set of configuration macros forces security features to be used at all times. All communication is authenticated (using Kerberos), and all communication is both encrypted (using triple DES) and has its integrity checked to make sure that messages are not modified or corrupted. Negotiation configuration variables are not included in this suggested configuration. The default (when undefined) will be to set
SEC_DEFAULT_NEGOTIATION=OPTIONAL
Note that this example configuration requires that all Condor daemons be version 6.3.3 or later, since previous versions will not have the ability to do secure communication.
KERBEROS_MAP_FILE = /path/to/etc/condor.kmap
Lines within the map file have the syntax
KERB.REALM = UID.domain.nameHere are two lines from a map file to use as an example:
CS.WISC.EDU = cs.wisc.edu ENGR.WISC.EDU = ee.wisc.edu
The configuration variable CONDOR_SERVER_PRINCIPAL defines the name of a Kerberos principal. If CONDOR_SERVER_PRINCIPAL is not defined, then the default value used is "host". A principal specifies a unique name to which a set of credentials may be assigned.
Condor takes the specified (or default) principal and appends a slash character, the host name, an '@' (at sign character), and the kerberos realm. As an example, the configuration
CONDOR_SERVER_PRINCIPAL=condor-daemonresults in Condor's use of
condor-daemon/the.host.name@YOUR.KERB.REALMas the server principal.
This form of authentication utilizes the ownership of a file in the identity verification of a client. A daemon authenticating a client requires the client to write a file in a specific location. The daemon then checks the ownership of the file. The file's ownership verifies the identity of the client. In this way, the file system becomes the trusted authority.
Authorization protects resource usage by granting or denying access requests made to the resources. It defines who is allowed to do what.
Authorization is defined in terms of users. An initial implementation provided authorization based on hosts (machines), while the current implementation relies on user-based authorization. Section 3.7.5 on Setting Up IP/Host-Based Security in Condor describes the previous implementation. This IP/Host-Based security still exists, and it can be used, but significantly stronger and more flexible security can be achieved with the newer authorization based on fully qualified user names.
Unlike authentication, encryption, and integrity checks, which can be configured by both client and server, authorization is used only by a server. The authorization portion of the security of a Condor pool is based on a set of configuration macros. The macros list which user/daemon will be authorized to issue what request given a specific access level.
These configuration macros define a set of users that will be allowed to (or denied from) carrying out various Condor commands. Each access level may have its own list of authorized users. A complete list of the authorization macros:
ALLOW_READ
ALLOW_WRITE
ALLOW_ADMINISTRATOR
ALLOW_CONFIG
ALLOW_IMMEDIATE_FAMILY
ALLOW_OWNER
ALLOW_NEGOTIATOR
DENY_READ
DENY_WRITE
DENY_ADMINISTRATOR
DENY_CONFIG
DENY_IMMEDIATE_FAMILY
DENY_OWNER
DENY_NEGOTIATOR
Each macro is defined by a comma-separated list of fully qualified users. Each fully qualified user is described using the following format:
username@domain/hostname
The information to the left of the slash character describes
a user within a domain.
The information to the right of the slash character describes
a machine from which the user would be issuing a command.
An example is
zmiller@cs.wisc.edu/bird.cs.wisc.edu
Within the format, wildcard characters (the asterisk, *) are allowed. The use of wildcards is limited to one wildcard on either side of the slash character. For example,
*@cs.wisc.edu/bird.cs.wisc.edurefers to any user that comes from
cs.wisc.edu,
where the command is originating from the machine
bird.cs.wisc.edu.
Another example,
zmiller@cs.wisc.edu/*.cs.wisc.edurefers to commands coming from any machine within the
cs.wisc.edu domain, and issued by zmiller.
A third example,
*@cs.wisc.edu/*refers to commands coming from any user within the
cs.wisc.edu domain
where the command is issued from any machine.
This flexible set of configuration macros could used to define conflicting authorization. Therefore, the following protocol defines the precedence of the configuration macros.
An example of the configuration variables for the user-side authorization is derived from the necessary access levels as described in Section 3.7.3.
ALLOW_READ = *@cs.wisc.edu/* ALLOW_WRITE = *@cs.wisc.edu/*.cs.wisc.edu ALLOW_ADMINISTRATOR = condor-admin@cs.wisc.edu/*.cs.wisc.edu ALLOW_NEGOTIATOR = condor@cs.wisc.edu/$(NEGOTIATOR_HOST) ALLOW_CONFIG = condor-admin@cs.wisc.edu/*.cs.wisc.edu ALLOW_IMMEDIATE_FAMILY= condor@cs.wisc.edu/*.cs.wisc.edu
This example configuration authorizes
any user in the
cs.wisc.edu domain to
carry out a request that requires the
READ access level
from any machine.
Any user in the
cs.wisc.edu domain may
carry out a request that requires the
WRITE access level
from any machine in the
cs.wisc.edu domain.
Only the user called condor-admin may
carry out a request that requires the
ADMINISTRATOR access level
from any machine in the
cs.wisc.edu domain.
Only the negotiator daemon, running as
condor on the machine defined by the
NEGOTIATOR_HOST macro is authorized
with the
NEGOTIATOR access level.
The administrator, logged into any machine within
the cs.wisc.edu domain is authorized at the
CONFIG access level.
And, the last line of the example presumes that there is a
user called condor, and that the daemons have all been started
up as this user.
It authorizes only programs (which will be the daemons)
running as
condor to
carry out requests that require the
IMMEDIATE_FAMILY access level,
where the commands originate from
any machine in the
cs.wisc.edu domain.
In the local configuration file for each host, the host's owner should be authorized as the owner of the machine. An example of the entry in the local configuration file:
ALLOW_OWNER = username@cs.wisc.edu/hostname.cs.wisc.eduIn this example the owner has a login of
username, and the machine's name is represented by
hostname.
This section describes the mechanisms for setting up Condor's host-based security. This is now an outdated form of implementing security at the level of machine access. It remains available and documented for purposes of backward compatibility. If used at the same time as the user-based authorization, the two specifications are merged together.
The host-based security allows control over what machines can join a Condor pool, what machines can find out information about your pool, and what machines within your pool can perform administrative commands. By default, Condor is configured to allow anyone to view or join your pool. You probably want to change that.
This section discusses how the host-based security works inside Condor. It lists the different levels of access and what parts of Condor use which levels. There is a description of how to configure your pool to grant (or deny) certain levels of access to various machines. Configuration examples and the settings of configuration variables using the condor_ config_val command complete this section.
Inside the Condor daemons or tools that use DaemonCore (see section 3.8 for details), most things are accomplished by sending commands to another Condor daemon. These commands are formed from an integer to specify which command, followed by any optional information that the protocol requires at that point (such as a ClassAd, capability string, etc). When the daemons start up, they register which commands they are willing to accept, what to do with arriving commands, and the access level required for that command. When a command arrives, Condor identifies the access level required, and checks the IP address of the sender to be sure it passes the various allow/deny settings in the configuration file for the given access level. If permission is granted, the command continues. If not, the command is aborted.
As expected, settings for the access levels in the global configuration file affect all the machines in the pool. Settings in a local configuration file only affect the specific machine. The settings for a given machine determine what other hosts can send commands to that machine. So, if machine foo is to be given administrator access on machine bar, place foo in bar's configuration file access list (not the other way around).
The following are the various access levels that commands within Condor can be registered with:
IMPORTANT: For a machine to join a Condor pool, the machine must have both WRITE permission AND READ permission. WRITE permission is not enough.
machine
).
Typically, very few
machines are in this list, perhaps only the workstations where the
Condor administrators or system administrators work,
or perhaps only the pool's central manager.
IMPORTANT: This access is given to a machine, and it applies to an entire pool. So, ADMINISTRATOR access for a given machine provides ANY USER on that machine ADMINISTRATOR rights (including users who can run Condor jobs on that machine). Therefore, grant ADMINISTRATOR access carefully.
Starting with version 6.3.2, Condor provides a mechanism for more fine-grained control over the configuration settings that can be modified remotely with condor_ config_val.
Host-based security access permissions are specified in configuration files.
ADMINISTRATOR and NEGOTIATOR access default to the central manager machine. OWNER access defaults to the local machine, as well as any machines given with ADMINISTRATOR access. CONFIG access is not granted to any machine as its default. These defaults work well, and should not be changed without a compelling reason. If machines other than the default are to have to have OWNER access, they probably should also have ADMINISTRATOR access. By granting machines ADMINISTRATOR access, they will automatically have OWNER access, given how OWNER access is set within the configuration.
The default access configuration is
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST) HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR) HOSTALLOW_READ = * HOSTALLOW_WRITE = * HOSTALLOW_NEGOTIATOR = $(NEGOTIATOR_HOST) HOSTALLOW_NEGOTIATOR_SCHEDD = $(NEGOTIATOR_HOST), $(FLOCK_NEGOTIATOR_HOSTS) HOSTALLOW_WRITE_COLLECTOR = $(HOSTALLOW_WRITE), $(FLOCK_FROM) HOSTALLOW_WRITE_STARTD = $(HOSTALLOW_WRITE), $(FLOCK_FROM) HOSTALLOW_READ_COLLECTOR = $(HOSTALLOW_READ), $(FLOCK_FROM) HOSTALLOW_READ_STARTD = $(HOSTALLOW_READ), $(FLOCK_FROM)
For each access level, an ALLOW or a DENY may be added.
Multiple machine entries in the configuration files may be separated by either a space or a comma. The machines may be listed by
To resolve an entry that falls into both allow and deny: individual machines have a higher order of precedence than wildcard entries, and host names with a wildcard have a higher order of precedence than IP subnets. Otherwise, DENY has a higher order of precedence than ALLOW. (this is how most people would intuitively expect it to work).
In addition, the above access levels may be specified on a per-daemon basis, instead of machine-wide for all daemons. Do this with the subsystem string (described in section 3.3.1 on Subsystem Names), which is one of: STARTD, SCHEDD, MASTER, NEGOTIATOR, or COLLECTOR. For example, to grant different read access for the condor_ schedd:
HOSTALLOW_READ_SCHEDD = <list of machines>
The following is a list of registered commands that daemons will accept. The list is ordered by daemon. For each daemon, the commands are grouped by the access level required for a daemon to accept the command from a given machine.
ALL DAEMONS:
The command sent as a result of condor_ reconfig to reconfigure a daemon.
The command sent as a result of reconfig -full to perform a full reconfiguration on a daemon.
STARTD:
All commands that relate to a condor_ schedd daemon claiming a machine, starting jobs there, or stopping those jobs.
The command that condor_ checkpoint sends to periodically checkpoint all running jobs.
The command that condor_ preen sends to request the current state of the condor_ startd daemon.
NEGOTIATOR:
COLLECTOR:
SCHEDD:
The commands that a condor_ startd sends to the condor_ schedd when it must vacate its jobs and release the condor_ schedd's claim.
The commands which write information into the job queue (such as condor_ submit and condor_ hold). Note that for most commands which attempt to write to the job queue, Condor will perform an additional user-level authentication step. This additional user-level authentication prevents, for example, an ordinary user from removing a different user's jobs.
MASTER: All commands are registered with ADMINISTRATOR access:
This section provides examples of configuration settings. Notice that ADMINISTRATOR access is only granted through a HOSTALLOW setting to explicitly grant access to a small number of machines. We recommend this.
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST) HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
HOSTALLOW_READ = *.ncsa.uiuc.edu HOSTALLOW_WRITE = *.ncsa.uiuc.edu HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST) HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
HOSTALLOW_WRITE = *.ncsa.uiuc.edu, *.math.uiuc.edu HOSTDENY_WRITE = lab-*.edu, *.lab.uiuc.edu, 177.55.* HOSTALLOW_ADMINISTRATOR = bigcheese.ncsa.uiuc.edu HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
\'' to continue a long list of machines
onto multiple lines, making it more readable (this works for all
configuration file entries, not just host access entries)
HOSTALLOW_READ = *.ncsa.uiuc.edu, *.cs.wisc.edu
HOSTALLOW_WRITE = *.ncsa.uiuc.edu, raven.cs.wisc.edu
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), bigcheese.ncsa.uiuc.edu, \
biggercheese.uiuc.edu
HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
HOSTDENY_READ = *.mil
HOSTALLOW_READ_SCHEDD = *.ncsa.uiuc.edu
HOSTALLOW_WRITE = *.ncsa.uiuc.edu
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), bigcheese.ncsa.uiuc.edu, \
biggercheese.uiuc.edu
HOSTALLOW_ADMINISTRATOR_NEGOTIATOR = biggercheese.uiuc.edu
HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
A new security feature introduced in
Condor version 6.3.2 enables more fine-grained control over the
configuration settings that can be modified remotely with the
condor_ config_val command.
The manual page for condor_ config_val on
page ![[*]](crossref.gif)
details how to use
condor_ config_val to modify configuration settings remotely.
Since certain configuration attributes can have a large impact on the
functioning of the Condor system and the security of the machines in a
Condor pool, it is important to restrict the ability to change
attributes remotely.
For each security access level described, the Condor administrator can define which configuration settings a host at that access level is allowed to change. Optionally, the administrator can define separate lists of settable attributes for each Condor daemon, or the administrator can define one list that is used by all daemons.
For each command that requests a change in configuration setting, Condor searches all the different possible security access levels to see which, if any, the request satisfies. (Some hosts can qualify for multiple access levels. For example, any host with ADMINISTRATOR permission probably has WRITE permission also). Within the qualified access level, Condor searches for the list of attributes that may be modified. If the request is covered by the list, the request will be granted. If not covered, the request will be refused.
The default configuration shipped with Condor is exceedingly restrictive. Condor users or administrators cannot set configuration values from remote hosts with condor_ config_val. Enabling this feature requires a change to the settings in the configuration file. Use this security feature carefully. Grant access only for attributes which you need to be able to modify in this manner, and grant access only at the most restrictive security level possible.
The most secure use of this feature allows Condor users to set
attributes in the configuration file which are not used by Condor
directly.
These are custom attributes published by various Condor
daemons with the SUBSYS_EXPRS setting described in
section 3.3.4 on page .
It is secure to grant access only to modify attributes that are used by Condor
to publish information.
Granting access to modify
settings used to control the behavior of Condor is
not secure.
The goal is to
ensure no
one can use the power to change configuration attributes to compromise
the security of your Condor pool.
The control lists are defined by configuration settings that contain SETTABLE_ATTRS in their name. The name of the control lists have the following form:
SUBSYS_SETTABLE_ATTRS_PERMISSION-LEVEL
The two parts of this name that can vary are PERMISSION-LEVEL and the SUBSYS. The PERMISSON-LEVEL can be any of the security access levels described earlier in this section. Examples include WRITE, OWNER, and CONFIG.
The SUBSYS is an optional portion of the name.
It can be used to
define separate rules for which configuration attributes can be set
for each kind of Condor daemon (for example, STARTD, SCHEDD, MASTER).
There are many configuration settings that can be defined differently
for each daemon that use this SUBSYS naming convention.
See section 3.3.1 on
page for a list.
If there is no daemon-specific value for a given daemon, Condor will
look for SETTABLE_ATTRS_PERMISSION-LEVEL .
Each control list is defined by a comma-separated list of attribute names which should be allowed to be modified. The lists can contain wildcards characters (`*').
Some examples of valid definitions of control lists with explanations:
SETTABLE_ATTRS_CONFIG = *Grant unlimited access to modify configuration attributes to any request that came from a machine in the CONFIG access level. This was the default behavior before Condor version 6.3.2.
SETTABLE_ATTRS_ADMINISTRATOR = *_DEBUG, MAX_*_LOGGrant access to change any configuration setting that ended with ``_DEBUG'' (for example, STARTD_DEBUG ) and any attribute that matched ``MAX_*_LOG'' (for example, MAX_SCHEDD_LOG ) to any host with ADMINISTRATOR access.
STARTD_SETTABLE_ATTRS_OWNER = HasDataSetAllows any request to modify the HasDataSet attribute that came from a host with OWNER access. By default, OWNER covers any request originating from the local host, plus any machines listed in the ADMINISTRATOR level. Therefore, any Condor job would qualify for OWNER access to the machine where it is running. So, this setting would allow any process running on a given host, including a Condor job, to modify the HasDataSet variable for that host. HasDataSet is not used by Condor, it is an invented attribute included in the STARTD_EXPRS setting in order for this example to make sense.