[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] condor security again

OK--I have a related question.  It is not strictly necessary
to actually run a schedd on an execute machine to submit a job, is it?
If someone does condor_submit -n schedd_name from an execute
host, is there anything to stop that?

And is there any way to make it so execute hosts can write to
the collector/negotatior but not the schedd?


On Thu, 16 Feb 2006, Matt Hope wrote:

On 2/16/06, Dr Ian C. Smith <i.c.smith@xxxxxxxxxxxxxxx> wrote:

--On 16 February 2006 13:29 +0000 Matt Hope <matthew.hope@xxxxxxxxx> wrote:

On 2/16/06, Dr Ian C. Smith <i.c.smith@xxxxxxxxxxxxxxx> wrote:
This follows up the earlier authorization thread
which seems to have gone a bit cold. I've been
having a look at the Condor configuration model
again and there seems to be no way
of enforcing a policy that execute hosts cannot be
used (potentially) as submit hosts without having
strong user authentication. If a rogue user
could install a client on an execute host it could then
be used to submit jobs (nasty!). My thinking is this:

At the very least you could spot this shortly after it happened since
the schedd would have to register itself with the collector to add any
jobs to the pool.

If you have a black list / while list of machines allowed/disallowed
from being schedd's you can spot em pretty quick with an automated

Not perfect I know but at least you can spot it happening

Hmm, our Condor jobs can only run at the very times no one
is likely to be around to keep an eye on things.

simple way

run an automatic job which looks at the collector and finds a bad
schedd (running on a machine you explicitly stated was not allowed)
and then execute a

condor_off -fast [machine] -schedd

Fairly simple script (and you can start by just catching people if you want)

If you want to get fancy you could pslist* the remote machine to find
the user name of the process owner


* or *nix equivalent

Condor-users mailing list

Steven C. Timm, Ph.D  (630) 840-8525  timm@xxxxxxxx  http://home.fnal.gov/~timm/
Fermilab Computing Div/Core Support Services Dept./Scientific Computing Section
Assistant Group Leader, Farms and Clustered Systems Group
Lead of Computing Farms Team