Re: [Condor-devel] Avoiding redundant executables in the SPOOL

[Alan De Smet <adesmet@xxxxxxxxxxx>]

The default assumption in Condor, the basis of much of our
security, is that a given Owner is a single person, and that we
don't need to protect an Owner from himself.  We do need to
protect one Owner from another Owner and this design does so as
the schedd includes the Owner in the hash file name.

(You can break this assumption, but as discussed, you have to do
a fair amount of work to lock thing down.  Even without the
changes I'm proposing, I would not want to officially support
such a configuration as secure.)

User's can't write files with names of their choosing into the
SPOOL.  The user badguy can't write a file file called
exe-goodguy-CmdHashMD5-12345 into the spool.  He may be able to
pick everything from "CmdHashMD5-" and on, but the "exe-badguy-"
prefix is enforced by the schedd.  

As such, we need a hash strong enough to avoid accidental
collisions, not hostile attacks.  MD5 is plenty secure enough for
that purpose.  It was designed to be cryptographically secure.
While recent research has shown a decided weakness, there is no
evidence that it results in poorly distributed results.  There is
a 2^128 chance of an accidental collision between any two files.
(The 2^64 would be the number of hashes you would need to take
before you would expect a collision.  As Condor currently only
handles 2^32 jobs in the queue simultaneously, it's not even
possible to hit that number.)


With regards to filesystems that don't support link(), I'm not
worried about it.  If link() fails, we just fall back to the old
way.  If link() lies (either failing with no error, or copying
the file), you've got a weird FS and should probably already know
it and are used to coping.  Indeed, Condor relies on link()
working elsewhere; there is a reasonable chance things are broken
already.  The fix in this case will be to disable shared
executables.  


Bruce Beckles <mbb10@xxxxxxxxx> wrote:
> In particular, suppose a bad person gets hold of the user's
> account and submits some jobs.  They are discovered and the
> jobs are condor_rm'd and the user changes their password, etc.
> If the bad person has hard linked to the hash path then their
> bad executables will still be around, even though the user and
> sysadmin may think everything is now okay.

If an account has been compromised, _everything_ the user can
create or modify is suspicious.  Every single file the user owns
or can write to directly or indirectly must be considered, and
this would include any hard linked binaries.  User compiled
binaries may be contaminated.  The user's login scripts may be
tainted.  A tainted replacement to "ls" might have been placed
into the user's path.  A running program (with unlinked binary)
might be lurking in the background.  You have a much deeper
problem than Condor can solve for you.

> Yes, "sharing" an Owner - the idea is that user B left a job in
> the queue and stopped using the system.  His account gets
> recycled to user A, but the job in the queue doesn't get
> removed first.  You could argue that this is poor housekeeping
> on the sysadmin's part (and indeed it is), but I know that it
> does happen in the real world.

If an account is recycled, the admin needs to clean up after it.
They're going to have to clean up databases (possibly full of
dangerous stored procedures) and the crontab and at queue.
Leaving a job in the queue when an account is recycled is a
security hole today.  That job left behind might run and can
write results anywhere the user A has permission to write, giving
B a vector to attack A.  User B might have confidential data that
would now be exposed to user A.  There isn't much Condor can do
to help here.

-- 
Alan De Smet                              Condor Project Research
adesmet@xxxxxxxxxxx                http://www.cs.wisc.edu/condor/