Disallow site auth limits in user configs.

[hjoliver]

Our head HPC guy thinks it is a design flaw that the site authorization limits can be overridden or disabled by users just by setting the same item in their user config, and I kind of agree.

Admittedly, I had forgotten that we knowingly do nothing to prevent this on grounds that users have complete control over their own processes so could hack the system in several ways to get around any such restriction if they wanted to.

However, hacking the system is one thing, simply setting a valid Cylc config item is another - that's too easy, it almost makes the site limits pointless.

If it is easy for us to disallow use of site_authorization in user configs, then I can't think of a good reason not to do so. We can (and should) still document that users have complete control over their own processes and so could subvert this if they want to - but at least then that will require a deliberate hack, with considerably more knowledge and effort, not just normal use of a Cylc config item.

---

Highjacking the Jupyter server config file loading mechanism is probably a step too far, but it seems we can use Python importlib tools to inspect the content of the user config module without properly importing it to sys.modules.

Currently on the PR, it works for cylc gui.

$ cylc gui
ERROR ~/.cylc/uiserver/jupyter_config.py: 'site_authorization' cannot be set in user config files

If agreed on the approach I can make it work for hub-based launch too.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[dwsutherland]

Wouldn't it make sense for this not_allowed list to be defined at the site config level by the administrators?

Because it's really a policy matter what the admins allow/disallow the user to do with access to themselves.

[dwsutherland]

Actually .. Strike this, reverse it ..

site_authorization should only be set at site level..
whereas user_authorization is set by the user, and bound by the site_authorization parameters..

[hjoliver]

We don't really need a list actually, I think there's only one relevant setting. The code all runs as the user, it's just that it doesn't make sense to have site_... settings in the user config file.

[oliver-sanders]

As discussed, this does not prevent a user from overriding the site configuration, so amounts to psudo security (making it look like something is secure when it isn't).

Making it look like this is secure / protected is worse for security than accepting that it isn't.

However, hacking the system is one thing, simply setting a valid Cylc config item is another - that's too easy, it almost makes the site limits pointless.

It's not pointless, the user has to explicitly overwrite the site policy, which is obviously not permitted by local policies. There are lots of policies which are upheld in this sort of manner, such as not giving your password to someone else, not mining bitcoin on corporate resource, not letting in hackers, etc.

We can always add more bells and whistles...

[hjoliver]

I don't buy that argument - it's as simple as this, really:

• there's no valid reason to set site auth limits in user config files
  • if it is present, it either violates site policy or is utterly pointless
• therefore, Cylc should not support that

Disallowing it makes the system more secure in that it becomes much harder to violate site policy. (Yes, that's "more", not "absolutely" - but security always has caveats, even for (e.g.) SSH).

Of course users can in principle hack around these kinds of restrictions, but very few could or would, and we can still strongly warn that site limits are in principle vulnerable. But simply disallowing it will prevent the vast majority if not all violations.

There are lots of policies which are upheld in this sort of manner, such as not giving your password to someone else, not mining bitcoin on corporate resource, not letting in hackers, etc.

Somewhat beside the point, but you can be sure that these behaviours would not merely be left to site policy if technical restriction was feasible!

Making it look like this is secure / protected is worse for security than accepting that it isn't.

It is the site_auth setting itself that is the primary culprit, optics-wise. If Cylc provides for site auth limits on users, there will inevitably be an expectation that Cylc does not support users violating the same limits by simply setting the same config item!

The other sensible approach would be to not provide the site limit setting at all - that would certainly make it 100% clear that users have full control over their own auth settings.

[oliver-sanders]

I understand your frustration, however, we investigated all of this at the time and determined that we we probably could not prevent users setting this value, even by legal means.

For example, your changes here can be easily side-stepped by using the CLI argument:

cylc gui --CylcUIServer.site_authorization={...}

Or by using your root level jupyter config:

# $HOME/jupyter_config.py
c.CylcUIServer.site_authorisation={...}

Both of which are perfectly legal.

For this and other reasons, we determined that there was no point in trying what you have attempted here, and why I discouraged you from trying! We do have our reasons!

But that doesn't mean that the feature is without purpose, it still provides value to us, a soft limit is still better than no limit. It makes you think before you cross it.

[hjoliver]

Good points @oliver-sanders - you've shown that a user config block as per this PR could still be avoided without outright hacking.

For the record, we've also discussed offline:

• renaming config items to remove the word "site" and thus avoid giving the impression of site limits that users can't override
  • not agreed, because the item is already in use in the wild and there's a perception that "site" is a helpful reminder to users if nothing else
• taking this PR, or similar, as a partial block, which would likely prevent almost all misuse by users
• or sticking with the status quo

Whichever we decide (I'll come back next week...) we should document the result very clearly, so we can always point to that if anyone complains (e.g.) that a site limit is not really a site limit...

[hjoliver]

OK ... if we could go back in time, my preference would be to NOT call normal user overrideable config a "site limit".

But we can't do that, and besides, the current config names are already being used in anger at Met Office.

I also concede that the word "site" may indeed be a useful reminder for users of the intended use.

I also concede that the solution tried on this PR is not perfect - it can be worked around without outright hacking.

But all things considered, my preference is still a partial block to users overriding site config via our normal config files.

1. this will stop almost all violations in reality; it requires deliberate intent to get around it, even if not outright hacking
2. it will not break any existing deployments (unless we don't want to bother users who are already violating site policy)
3. I don't really agree that this gives a false impression of security more than the "site" name itself already does
   • (And in any case we should clearly document and WARN that it is not possible for Cylc to truly enforce this, because the user owns their own processes after all)

@cylc/core - are you happy with this? The only real point of disagreement I can see is 3. which is very subjective - in which case, a reminder: to the extent that impressions of security matter, I raised this after ESNZ's HPC technical lead strongly objected to our status quo.

[oliver-sanders]

A defence that only covers some situations but not others is somewhat dubious from a security perspective, however, as long as this is reasonably documented and explained, I'm happy accepting a partial block.