Re: [HTCondor-users] Security of "Owner"

["Kandes, Martin" <mkandes@xxxxxxxx>]

Hi Todd,

That does help. I've already got password authentication setup for the pool. I did also see/read through some of the instructions on how to try SSL as well. Maybe I'll give that a go as well eventually too.

Thanks,

Marty

________________________________________
From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx] on behalf of Todd Tannenbaum [tannenba@xxxxxxxxxxx]
Sent: Tuesday, October 18, 2016 5:30 PM
To: HTCondor-Users Mail List
Subject: Re: [HTCondor-users] Security of "Owner"

On 10/18/2016 6:32 PM, Kandes, Martin wrote:
> Hi all,
>
> I'm trying to isolate execute nodes by specific users using START
> expressions. e.g., [1]. I did one simple test [2], which appears like
> another user cannot hijack another Owner's name. Are there any other
> security implications I should be thinking of?
>

So the default config has the schedd securely authenticating the user
who is submitting the job via filesystem authentication and setting that
to the Owner, so that is all good.

The question you should ask yourself now is how is the startd (on the
execute node) setup to authenticate that is it talking to a "trusted
schedd" ?  By a trusted schedd, I mean one that can be trusted to have
securely authenticated the submitting user.  HTCondor uses a chain of
trust - the schedd authenticates the submitting user, and then the
startd authenticates the schedd.  If your pool is setup to use some form
of credential based authentication (i.e. authentication methods like
PASSWORD, GSI, SSL, KERBEROS, ...), you are probably good.  If your pool
is using host-based authentication (like *.my.domain.edu), you need to
trust all users that can login to the trusted hosts to deal with the
fact that a determined malicious user could login to a submit node and
run their own hacked/modified/misconfigured schedd binary which could
misrepresent the Owner to the startd on the execute node.

HTCondor supports all sorts of authentication mechanisms; see Section
3.6 of the HTCondor Manual.  If your nodes already have GSI host certs
installed, I'd use that.  If your nodes already SSL host certs installed
(and if you use Puppet, they probably already do), you could go with
that - see HOWTO recipe at
    https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToEnableSsl
And finally if you don't have either of those, it is quick and easy to
install a "pool password" file on each node that is readable only by
root, and tell HTCondor to only trust other daemons that also know the
secret.  See the Manual or the HOWTO recipe at

https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToEnablePoolPassword

Hope this helps
Todd



> Thanks,
>
> Marty Kandes
> UCSD
>
> [1]
>
> START = (Owner == "mkandes")
>
> [2]
>
> [1626] emfajard@pcf-osg ~$ condor_qedit 11676.0 Owner mkandes
> Update of attribute "Owner" is not allowed.
> Transaction failed.  No attributes were set.
>
>
> _______________________________________________
> 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/