Privilege escalation by calling SubmitJobs?

[sync-by-unito]

SubmitJobs calls a private helper getQueueOrCreate which will create a queue if it doesn't exist. The user can do this if:

• autoCreateQueues is set to true in config.yaml
• the user has permissions.SubmitAnyJobs

I think the user should also need permissions.CreateQueue to create a queue, or else autoCreateQueues renders that privilege meaningless. Thoughts?

steffnova

┆Issue is synchronized with this Jira Task by Unito

[sync-by-unito]

➤ Andrew Cone commented:

robertdavidsmith perhaps you have thoughts on this?

[sync-by-unito]

➤ JamesMurkin commented:

Hey so I agree this is a weird and something we want to remove asap (once we migrate an internal user off it).

However I don't think we want to make the user have CreateQueue perms, at minimum we would need to introduce a new permission that controlled it, I'll explain why.

• SubmitAnyJobs is a admin permission that allows a user to submit to any queue. It also causes Armada to create non-existent queues in certain circumstances as you describe above. One thing to note here is that that Armada controls the queue creation, users with SubmitAnyJobs can't control the queue that is created beyond its name
• CreateQueue is an admin permission that allows you to create and edit any existing queue. This permission therefore needs to be highly restricted, as they could edit any queue and change who can submit to queues, what priority queues have

Giving SubmitAnyJobs to users currently is quite "safe" in that at worst they can use up other peoples queue "share". Whereas giving them CreateQueue would allow them to completely change all queues in Armada itself.

Either we:

• Create a new perm that allows this auto queue creation
• Split CreateQueue into Create and Update (then giving people is quite "safe" as they can't edit existing queues)
• Wait for us to migrate the internal use and just delete all this auto creation

[sync-by-unito]

➤ robertdavidsmith commented:

On balance I think giving users a special "allow auto creation" perm is the best idea, as this whole thing is really "wacky" and best kept on a tight leash.

JamesMurkin is currently researching if we can bin auto-creation altogether, which would be even better. That would involve finding an alternative for GR's internal use case. So suggest parking until James has an answer on this.