3.10 Security In Condor

This section describes various aspects of security within Condor.

  
3.10.1 Running Condor as Non-Root

While we strongly recommend starting up the Condor daemons as root, we understand that that's not always possible. The main problems this causes are if you've got one Condor installation shared by many users on a single machine, or if you're setting up your machines to execute Condor jobs. If you're just setting up a submit-only installation for a single user, there's no need for (or benefit from) running as root.

What follows are the details of what effect running without root access has on the various parts of Condor:

condor_startd

If you're setting up a machine to run Condor jobs and don't start the condor_startd as root, you're basically relying on the goodwill of your Condor users to agree to the policy you configure the startd to enforce as far as starting, suspending, vacating and killing Condor jobs under certain conditions. If you run as root, however, you can enforce these policies regardless of malicious users. By running as root, the Condor daemons run with a different UID than the Condor job that gets started (since the user's job is started as either the UID of the user who submitted it, or as user ``nobody'', depending on the UID_DOMAIN settings). Therefore, the Condor job cannot do anything to the Condor daemons. If you don't start the daemons as root, all processes started by Condor, including the end user's job, run with the same UID (since you can't switch UIDs unless you're root). Therefore, a user's job could just kill the condor_startd and condor_starter as soon as it starts up and by doing so, avoid getting suspended or vacated when a user comes back to the machine. This is nice for the user, since they get unlimited access to the machine, but awful for the machine owner or administrator. If you trust the users submitting jobs to Condor, this might not be a concern. However, to ensure that the policy you choose is effectively enforced by Condor, the condor_startd should be started as root.

In addition, some system information cannot be obtained without root access on some platforms (such as load average on IRIX). As a result, when we're running without root access, the 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 Condorstartd 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.

condor_schedd

The biggest problem running the schedd without root access is that the condor_shadow processes which it spawns are stuck with the same UID the condor_schedd has. This means that users submitting their jobs have to go out of their way to grant write access to user or group condor (or whoever the schedd is running as) for any files or directories their jobs write or create. Similarly, read access must be granted to their input files.

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_master

The condor_master is what spawns the condor_startd and condor_schedd, so if want them both running as root, you should have the master run as root. This happens automatically if you start the master from your boot scripts.

condor_negotiator

condor_collector

There is no need to have either of these daemons running as root.

condor_kbdd

On platforms that need the condor_kbdd (Digital Unix and IRIX) the condor_kbdd has to run as root. If it is started as any other user, it will not work. You might consider installing this program as a setuid root binary if you can't run the condor_master as root. Without the condor_kbdd, the startd has no way to monitor mouse activity at all, and the only keyboard activity it will notice is activity on ttys (such as xterms, remote logins, etc).

  
3.10.2 UIDs in Condor

  
3.10.3 Root Config Files