Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] condor security again
- Date: Thu, 16 Feb 2006 15:47:36 +0000
- From: Matt Hope <matthew.hope@xxxxxxxxx>
- Subject: Re: [Condor-users] condor security again
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
> > job...
> >
> > 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
Matt
* or *nix equivalent