Re: [HTCondor-users] condor_ssh_to_job

[Mark Calleja <mc321@xxxxxxxxx>]

On 13/08/14 17:10, Brian Bockelman wrote:

On Aug 13, 2014, at 10:48 AM, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:

Hi Steve,

(DOE regulations aside... I accept not all things in life are technical issues)

Hm - realized I wasn't being clear on this point.

If your site policy forbids interactive access to worker nodes (that's fine - we do at Nebraska), then turning off condor_ssh_to_job is a fine thing.  It'll help remind folks who "forget" they agree to the policy.

The reason I don't login interactively to FNAL worker nodes is because it's against the AUP I agreed to, not because you disabled condor_ssh_to_job.  Technical mechanisms are no substitute for establishing a trust - ultimately a social relationship (AUPs, user education, etc).

Too often we forget only consider only the technical mechanisms to influence behavior at the exclusion of social mechanisms.

To use Keith's example, my theory is that if he wrote in the MOTD "Users may use condor_ssh_to_job for up to 5 minutes at a time and only for debugging purposes.  Violators will have their access removed and their group lead notified", the end result would be the same as if he spent several days working on restricted shells.

Brian

Without condor_ssh_to_job: User can run any arbitrary code.
With condor_ssh_to_job: User can run any arbitrary code (but now has better tools for debugging his or her code).

So, by "uncontrollable access hole", I assume you mean "the user can do the same set of activities as before, but now some are easier".

Keith: Any user job can start hundreds of processes and occupy slots indefinitely.  This is true regardless of condor_ssh_to_job.  If you don't want the user to have the ability to do this, there are other knobs you need to turn, not condor_ssh_to_job.

Again - if (from a security POV) you can't trust your user with condor_ssh_to_job, I question whether you should trust them to run code in the first place.

Brian

On Aug 13, 2014, at 10:40 AM, Steven C Timm <timm@xxxxxxxx> wrote:

We disable this feature at Fermilab and I would strongly suggest that any 
other cluster do the same, it is an uncontrollable access hole.  If you care
about security at all don't turn it on.

Steve Timm


From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx] on behalf of Keith Brown [keith6014@xxxxxxxxx]
Sent: Wednesday, August 13, 2014 7:13 AM
To: HTCondor-Users Mail List
Subject: Re: [HTCondor-users] condor_ssh_to_job

so, what is the point of condor_ssh_job? if a user can start hundreds of processes he can just ssh into his job and occupy slots indefinitely.  there must be a way for an administrator to control access to condor_ssh_job.




On Tue, Aug 12, 2014 at 10:32 PM, Rich Pieri <ratinox@xxxxxxx> wrote:
On 8/12/2014 8:11 PM, Keith Brown wrote:

how can I set restrictions when a user ssh's to a job on a machine? I would
like to set a shell with has access to very little commands and I want a
timeout after 5 minutes.

Not really possible. Condor permits users to run pretty much any code
they want. This can be used to bypass any chroot() jails and limited
shells that you create. For example, a custom sshd that ignores a user's
default shell and home directory and uses whatever environment that
Condor provides instead.

If you don't want users running interactively on compute nodes then
don't give them any access to those nodes. Put them behind a firewall
and only allow access via the job submission system.

--
Rich Pieri <ratinox@xxxxxxx>
MIT Laboratory for Nuclear Science

Just to give a different perspective on the subject, condor_ssh_to_job is not the only way to provide visibility of a user's running job(s). Here at Cambridge we've used a web-based solution [1] for "a long time". This allows the user to browse all his/her files in a job's scratch space, without the need to log into that node, and the fact that all requests are done via a publicly facing web server means that they can access their files from any client browser, even if the jobs are running on an execute host on a private LAN. I'm sure I've heard of similar solutions elsewhere in the past, though I can't recall specific examples.

Mark

[1] http://www.ucs.cam.ac.uk/scientific/camgrid/technical/viewer