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

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