Re: [HTCondor-users] condor_ssh_to_job

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

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
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>> 
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
>> 
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>> 
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
> 
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/